Since we're using multi-part uImage format, we can add the FDT as
a seperate "blob" in the uImage, if the used U-Boot version is not
"FDT enabled".
This is used for example for our Verdex target. Currently I've got
a local hack in the platform/u-boot/Jamfile, looking into pulling
in the FDT files and a proper Jam setup to do that properly...
This detects everything up to ARMv6 right now. Need to check more
recent ARM ARMs for ARMv7 detection.
The detected details get passed on to the kernel, which can use
the pre-detected info for selecting right pagetable format and such.
Copyright removal of Axel done after agreement with Axel @ BeGeistert
that for files that were copy/pasted from x86 arch and then fully
replaced the implementation, removal of original copyright holder is
allowed, since their actual code is gone ;)
Pass the BHandler object that opened the about window to BAboutWindow.
When the window closes, send a kAboutWindowClosed message back to the
handler. This allows the handler to set the variable to NULL.
Implement the new about dialog constructor in all apps that use it.
Remove the old constructor. This now works reliably for all cases I
tested without crashing and does the right thing on close. The setup
and teardown is a bit more complicated than I wanted though.
Unfortunately this seems to be necessary when not using a BAlert.
Fetching the app icon does not work reliably yet. This is because for
replicants the app may not be running. I may have to pass the icon in
instead of grabbing it from the signature.
* Grabs the app icon and version from the resource file.
* Allow you to specify the copyright holder instead of hardcoding
"Haiku, Inc."
* Support multiple extra copyright fields.
* Modify BAlert to take a custom icon.
* Set the custom icon of the BAlert to the app icon.
* Also set the app version.
* Convert BAboutWindow to derive from BWindow
* Place a 128x128 icon and fill out a scrolling BTextView
with options such as authors, version history, copyright,
license, etc. Still needs some work but is coming along.
* Add the word Version to the version line, i8n'ed of course,
and tweak the info box and default sizes.
Also gave the Up Arrow and Down Arrow a scroll arrow. The up arrow works
but the down arrow doesn't because the sibling menu is stealing the
MouseDown event."
instead of trying to make it follow fExpando just make it a fixed
size on creation. It is invisible and extends to the bottom of the
screen. fExpando grows inside it, and the window follows fExpando.
When the window grows taller than the screenframe the arrows are
added. You can scroll with the mouse wheel, but I haven't yet gotten
scrolling to work from clicking. Deskbar still crashes when going
from Mini mode to vertical expando mode. I have no idea why.
Rename ScrollMenu.cpp to MenuScrollView.cpp
Half step towards making this class work as part of Deskbar without
extending any other classes. Scrolling works both with mouse and
scroll wheel. Redraws on scroll, need to make that work better.
Also need to move classes out of the Interface Kit and into Deskbar.
Modify the ScrollMenu class to use the layout kit by adding a constructor that doesn't take a view.
Get the BScrollMenu class to follow the size of the BMenu it is a parent of. Adjust the scrollers to appear in the right places. This is a WIP but it works in Deskbar, next step is to integrate this directly into BMenu with the scrollers as children of the menu instead of as children of the BScroller class.
Rebase changes on top of master
Deskbar scrolling works for the most part, just need to fix the
bottom arrow and clean up a bit.
This is to make sure all ARM platforms will benefit from planned work on this
MMU/CPU code. The less code duplicated, the better.
Compile-tested for all supported ARM platforms
This also implements the fault handler correctly now, and cleans up the
exception handling. Seems a lot more stable now, no unexpected panics or
faults happening anymore.
* Before, you had to have both, the text view layout item, and the label
layout item or else nothing would ever be visible.
* Now you can only create the text view item, and it will still work.
* Also, no matter the order you added the layout items, they would always
put the label on the left, and the control to the right.
* You can place the label and text view layout items anywhere now, although
you should keep in mind that the view spans over their frame unions; IOW
they should always adjacent to each other, but not necessarily horizontally
and left to right.
* No longer uses a fixed label spacing, but utilizes
BControlLook::DefaultLabelSpacing() instead.
* However, the spacing is always added to the right of the label, no matter
how you place it in the layout. Maybe one wants to add a SetLabelTextViewGap()
like method.
* Adjust BTextView to use B_COMMAND_KEY instead of B_CONTROL_KEY
for wordwise navigation and jumping to the top and bottom.
This requires a shortcut, which is only installed if there is
none already (for the groups B_LEFT_ARROW/B_RIGHT_ARROW and
B_HOME/B_END). As a result, wordwise navigation no longer works
in Mail, for instance.
* drop "protected" from bsd-compat header sys/cdefs.h, as that define
pollutes the global namespace and at least FreeBSD doesn't provide
it anymore
* remove all uses of that macro from libedit, which seems to be the
only user in our tree
* The only implementation that would accept more than 2 TB was the one in
scsi_disk. But even that one was limited to 63 TB.
* Now there is a new utility function devfs_compute_geometry_size() which
does it correctly for sizes up to 2^64 which should be good enough for
quite some time :-)
* This fixes bug #8992.
* When we do not have a predefined model string, we now try to parse
the reported model string into something that is at least usable,
and should look comparable to what we have now.
* For models where the parsed type string is acceptable, we could remove
the predefined ones.
- BNavMenu now keeps its own copy of the cached types list that's passed to it.
In some circumstances it could happen that the container window would
delete the list and consequently the nav menu would wind up with a pointer
to an invalid object. Probably a regression from the async mouse tracking
rewrites.
