This issue only manifested itself when the navigation toolbar was shown.
The scrollbar appeared to have no border while the rest did. This issue
manifested when the scrollbar insets were adjusted in hrev49654. The
scroll bar insets were really hiding the bug underlying bug though.
I'll try to explain what was happening and how I fixed it. The PoseView
container, called BorderedView, was showing its top border when the
navigation bar was hidden, and hiding its top border when the navigation
bar was shown. This (almost) worked because the menu bar provided a
bottom border while the navigation toolbar didn't. However hiding
BorderedView's top border also hid the scroll bar border.
My solution was to draw a bottom border on the navigation toolbar and
then remove the top border from BorderedView unconditionally. So either
the menu bar or the navigation toolbar provides a bottom border and the
BorderedView has no top border.
Fixes#12392
"BToolBar" matches the current convention ("BStatusBar", "BMenuBar", etc.)
I've no idea what I was thinking when I renamed this before...
Also adjust all users of BToolBar (Tracker and ShowImage).
Sorry this commit is so big, but I couldn't figure out how to do this
incrementally without breaking things.
I wasn't able to just merge Aldeck's branch, as it was a partial refactor
of Tracker and didn't just rewrite the UI creation code to use layouts,
and the changes for PM (e.g. addon loading, virtual directories) made it
very hard to merge (it doesn't even compile after an automerge) so rather
than spending time on that, I decided it'd be better to recreate his work.
Miscellaneous notes:
- This partially cleans up BPoseView & subclasses and BContainerWindow &
subclasses -- none of the subclasses and child views abuse the parent's
state, child views, or layout now.
- BFilePanel and BDeskWindow are not on layouts, because:
* BFilePanel docs in the Be Book instructed developers that wanted to
modify BFilePanel's layout to just use FindView() and then move the
views around. Obviously making it use layouts will break all BeOS
apps that do this, and there are a lot of them (Pe, WonderBrush are
just two examples.) I've added a note to the TODO list for R2 to create
a layout-compatible API for this.
* Some replicants (Workspaces, for example) rely on manipulating
BDeskWindow's drawing state. This is incompatible with layouts, as
at least in the case of Workspaces, it breaks a layouted version
of BDeskWindow entirely.
- I noticed a lot of #ifdef BEOS_VERSION ... gunk in the code. Tracker
probably didn't build on BeOS just before this commit, and now it
won't for sure, so I intend to go through and clean that out in the
near future.
This commit also fixes:
- enhancement #4996 (make Tracker's navigator use vector icons)
- bug #3039 (resizing OpenWithWindow flashes the blue border)
- bug #3889 (OpenWithWindow redraw errors)
- a regression that was a side effect of "dynamic_cast<BDeskWindow*>(this)"
always returning NULL when run in the constructor. I just added a "bool
isDeskWindow" to BContainerWindow's constructor that is only set to true
by BDeskWindow.
- a copy&paste error in VirtualDirectoryPoseView that was passing "uint32
resizeMode" as "uint32 viewMode".
Thanks to Alexandre for his original branch (it was a very useful
reference), Axel (for some miscellaneous advice & encouragement),
Adrien & Humdinger (for user interface review), and Diver (for user
interface review & testing).
BNavigator shouldn't update its location until AllAttached(). Otherwise,
it might immediately trigger a redraw, and in such a case, the
navigation buttons wouldn't yet have had a chance to load their icon
resources, leading to a debug assert in BPictureButton due to said
images not being present, but required.
