... from TeamMenuItem and WindowMenuItem.
It was confusing having Name(), Label(), and TruncatedLabel().
Name() == Label() because Label() never changes, the displayed
Label stored in TruncatedLabel() in both TeamWindowItem and
WindowMenuItem (remember they both inherit from
TruncatableMenuItem so they get that for free). So Name() was
redundant, by getting rid of it there is just Label() and TruncatedLabel()
which is all we need!
And add a SetLabel() that sets the truncated label when the label gets set.
This will be useful so we can compare the truncated label to the normal label
to tell if the label is truncated or not.
* Create a new TTruncatableMenuItem class to store the truncated string
and share the label truncation code between TTeamMenuItem and
TWindowMenuItem. In the future more shared code may be added to
this class, if so, the class name may change.
* The TTeamMenuItem and TWindowMenuItem classes inherit from
TTruncatableMenuItem, which inherits from BMenuItem.
* Make sure to truncate the label before drawing it in all cases.
* Some other related refactoring.
Fixes#9507
* Increase kVPad to 2.0f in ExpandoMenuBar matching the
constant in WindowMenuItem
* Also replace a hardcoded instance of 4.0f with kVPad * 2
* Remove TTeamMenuItem::DrawContentLabel(), move code to DrawContent()
* Cleanup label truncation code in TTeamMenuItem, still needs work.
* Rename WindowMenuItem::FullTitle() to Name() matching TeamMenuItem
* Move the code to set all label related variables in SetLabel() in
TeamMenuItem
* Change WindowMenuItem::SetRequireUpdate() to take a bool parameter
* Make WindowMenuItem::Initialize() private and rename it to _Init()
* Rename WindowMenuItem::ExpandedItem() to SetExpanded()
* Truncate WindowMenuItem label like we are doing TeamMenuItem
* Rename all WindowMenuItem::Title* methods and variables to Label*
Add private BMenu::_SetMenuLayout() method. Set TExpandoMenuBar
as a friend class in BMenu to call this method. A little hacky,
but, this keeps SetMenuLayout() from being exposed as part of
the public API.
Don't destroy and rebuild the ExpandoMenuBar when switching from
horizontal to vertical mode. Instead build the TExpandoMenuBar
when the application starts and then switch it from B_ITEMS_IN_ROW
to B_ITEMS_IN_COLUMNS by using the newly added _SetMenuLayout()
method.
When we resize from vertical to horizontal, recalc the max
menu item widths, this resizes the application menu items so
that they take up the right amount of space.
Since we no longer destroy the menu bar we no longer have to
save whether menu items are expanded or not in a separate list.
Instead we can store that information in directly in
TExpandoMenuBar. This removes a lot of code.
Fixes#9350
* Add Icon() and SetIcon() methods.
* Remove HasLabel() and SetHasLabel() methods, ExpandoMenuBar now gets
this information from the settings file directly, rather than storing
and syncing this information with the TTeamMenuItem class.
* Move SetOverrideWidth(), SetOverrideHeight(), and
SetArrowDirection() implementations to header.
* You can now insert arbitrary text only if the following or previous
placeholder does not resolve to an empty value using the %<, %> and
%- placeholders.
* Additionally, any non-alpha numeric character between % and the
placeholder character will only be displayed if the placeholder does
not resolve to an empty value, too.
* All of this allows you to get rid of the extra space between
"Terminal" and ":" before the current path -- which is now the
default.
302 and 303 redirects must convert POST requests to GET (and remove the
POST data).
Fixes the following problems (at least):
* Login to github going to the "unicorn!" page
* Gmail failing to load and staying at the loaderbar page
Before removing each of these, I verified that:
* there was already a HVIF of the icon in this rdef file
* the "MICN" constant was not used anywhere in the tree
There are a few icons left (e.g. BeBox icon) that don't have HIVF
equivalents (at least not in this file.)
There are a few left here that I didn't delete because the function does
more than just call up to the parent class, so someone with more knowledge
of the media kit than I do will have to go over those.
* When RemoveSelf() is called, we do not own our own layout items, so
we must not delete them.
* However, we do own them when we still have layout items left when
we get deleted ourselves.
* This fixes removing/adding a child view to a view without deleting
it inbetween (like the new Network preferences will do).
* Optimized item removal -- not a good idea to always remove item 0.
The version of this in src/add-ons/media/media-add-ons/tone_producer_demo/
is virtually identical, plus it is under a more permissive license
(Be Sample Code vs. BSD 3-Clause) and already fixed for 64bit.
