* at least for gcc2, we used to leave the 'os' subfolder in there,
which may have caused problems when Haiku's headers have changed
since the last time the compiler was built.
Make it clear that the values provided by the escapement_delta struct are an
input to App Server which allows the user to specify extra horizontal space around each character and is not an output provided by App Server.
If PeerAddress is cleared before invoking GetLocalAddress() we make sure
it won't contain any garbage data in a very unlike case when getsockname()
fails.
Position the text control vertically in the middle of the ramp in
the case that the text controls are pushed down so that the red, green,
and blue text controls are next to the red, green, and blue ramps.
In a few cases we were doing the work of _LayoutView() twice because
we called _LayoutView() and then called ResizeToPreferred() which called
_LayoutView() again.
Now only call ResizeToPreferred() which calls _LayoutView().
* Also change kMinCellSize from a uint32 to a float so that it can be used
with std::min() and std::max() instead of min_c() and max_c().
* Set the text controls sizes and margins based on the font size. Also rework
_TextRectOffset() so that it will get the right spacing from by dividing the
palette frame by 3.
* Replace bare numbers and refactor with calculation or magic constant.
* Create a private method _TextRectOffset() which calculates and
returns the vertical text rect offset to use based on the font size.
* Replace 2.0 with new kBevelSpacing constant where appropriate.
* fPaletteFrame calculation in _LayoutView() was refactored but should
not have changed.
Since hrev45725 we no longer resize fixed sized menu fields to their preferred
height in the constructor so as to be backwards compatible with the behavior on
BeOS R5. As a consequence though, the menu fields in Mail are now a bit too
tall so this commit tweaks the menu fields to be just a bit shorter matching
the height of the text controls.
That commit switched to a single string column for representing
breakpoint locations, but neglected to update the case of a breakpoint
in a non-debug function to actually format the address as a string
appropriately, leading to those simply showing no data since then.
Since some time now, we construct minimal dwarf image debug infos
for release images if they contain frame unwind information, in order
to allow using that to unwind the stack in as many cases as possible.
As such, it's entirely possible that such an image may be asked for
statement information regarding a function that isn't in fact compiled
with debugging. As such, we need to simply fall back to disassembly
rather than failing entirely. Fixes setting breakpoints in such
functions (i.e. anything in a release version of libstdc++).
Fixes#9816
It is no longer necessary, or even desirable for us to set the max
content width of the menu bar of a BMenuField now that BMenuItem
truncation and BMenuField sizing are working.
The user may, however, wish to set the max content width of the menu
bar of a BMenuField themselves like so:
menuField->MenuBar()->SetMaxContentWidth(width);
and the Interface Kit will automatically deduct the left and right
margins from the width including the space used by the drop down arrow.
When a filter is active, only expand parent nodes if either a) there is
only one matching parent, or 2) the match actually hit a function
contained in it. This allows the case where the intent of the filter is
to find a particular set of files or subdirectories to be handled more
efficiently.
ImageFunctionsView's filtering field now allows shell-style glob matches
rather than just simple direct string matches. Implements remaining
part of #7955.
Store the filter match index on the SourcePathComponentNode so we can
retrieve it directly when drawing instead of having to recompute the
position of the match every time.
- ImageFunctionsView now contains a text input allowing one to specify a
filter for its contained functions.
- When in filtered mode, the previous flattened view is used rather than
the hierarchical tree.
- The matching portion of the string is highlighted. However, currently
only simple string matches are supported.
* After examining MacOS toolbox roms, I think i've got
this nailed down. The MacOS Toolbox rom contains chrp
code at the top and binary code at the bottom.
* The Raw format for the chrp seemed to cause issues with the
OpenFirmware boot process on some systems. NetBSD uses a '-'
file type.
* The format of the chrp seems a lot more sensitive across machines
than described. Ensure our returns and spaces are even.
* Booting with the 'c' key is still working on my older OpenFirmware
machine with the chrp script. The bitmap logo is a half black, half
white box.
* I removed the &device; alias for now for troubleshooing. It also may
of been causing compatibility issues. More testing is needed.
* It seems like not all NewWorld OpenFirmware
versions support booting from CHRP scripts.
* Move Haiku elf bootloader into bootloader.b
type tbxi. As it is in the blessed directory
it is picked up by cd:,\\:tbxi
* Adjust bootinfo.txt to point to bootloader
&device; ensures that the image can be started
regardless of source media
* Adjust bootinfo.txt to use \\ as base. \\ is an
alias for the blessed folder on the boot media
* Rename ofboot.b to ofboot.chrp to avoid confusion
* Add .txt, .html to hfs.map to identify them properly
* The haiku-boot-cd-ppc.iso now boots on my G3 PowerBook
by holding the 'c' key at startup. The boot menu colors
are incorrect (white background) but it is a step in
the right direction.
* New chrp script. Blank icon for the moment, if someone
could figure out how to make a chrp icon that would be
neat.
* Tested working on qemu and real hardware. Need to test
on a more modern PowerPC Mac however.
* After lots of testing and playing, our v6 stack
just isn't ready for this level of prime time as
we lack IPv6 address scope flags.
* Fixes regression in #9594
