Fixes#9753 (for real this time)
Don't resize the menu field when the menu bar resizes, the menu
field stays the same size because we'll need to use it's width to
check when the menu bar width has expanded beyond its width.
Then, if the selected menu item expands the menu bar to a width
greater than the width of the menu field resize it to the menu field
width.
* Factor out the code to add some data to the about window, with a header and a content under it
* Make this method public so it's possible to add custom entries in an about box
* If the method is called with only the header or only the content, the text is added non-bold and non-indented (like the description entry*).
* Make the header text bold. I'm not sure it looks that good, after all. Thoughts ?
...a source path-based tree of all the image's functions, and
consequently organizes them into a nested hierarchy similar to the
on-disk directory structure in which they were originally found (or at
least, as close as we can get from the DWARF info).
Fixes#9753
This changes the preferred app menu field to no longer resize itself
based on the item width and instead always take up the rest of the
available space in the window. For narrower items this means that there
will be empty space to the right where there wasn't before. For items
wider than the available width of the window (like the example in #9753)
this means that the item will be truncated when selected.
AFAIK this was always a problem and was not caused by my recent work on
menu fields, we just didn't notice it because it's rare that an application
name in English at the default 12pt font size is wider than the available
space.
That being said, this fix is a band aid, the real fix is to convert this
window to use the layout APIs so that if you have an application that is too
wide to fit then the window will resize itself to fit the new item. There are
other some layout problems in this window too. Unfortunately, like Find, this
window has not been updated in aldeck's Tracker layout branch. Luckily,
converting this window to use the layout API is a lot less work than Find was.
If the menu field is not fixed size than the width of the menu bar
should depend on the menu item contents so just do the default and
get the Bounds() without any extra resizing.
Remove no longer needed header includes, most that I recently added
a few that were already there but just aren't needed anymore. Don't
use BPrivate::MenuPrivate namespace.
Just a few commits ago I moved the label truncation code out of
BMenuItem and into BMCMenuBar because the truncation had to happen
outside of BMenuItem. Turns out, that wasn't true so I'm moving the
label truncation back into BMenuItem and removing the _DrawItems()
method from BMCMenuBar.
Note that the code is not a copy of what was there before, but, the
updated version I created for BMCMenuBar. The main difference is that
I use menuPrivate.Padding() instead of GetItemMargins() and I always
use the width of the parent menu frame instead of using fBounds even
if the state is not MENU_STATE_CLOSED. These are changes needed for
BMCMenuBar but should work just as well for a regular BMenu.
...instead of in BMenuItem and remove the truncation code from BMenuItem.
The label truncation code cannot work in BMenuItem because the super
menu helpfully resizes itself to fit the menu item. So, instead we do the label
truncation in BMCPrivate making sure that BMenuItem there can't expand the
BMCMenuBar because we set the width to fMenuField->_MenuBarWidth()
explicity.
Note that this only truncates the label in BMCMenuField, i.e. the label inside
the menufield, it does nothing to the labels of the menu items in the attached
BMenu or BPopUpMenu which is exactly what we want.
Was passing !fixedSize into the view flags of BMenuBar, which made no sense.
Stop doing that, set fixedSize to true instead.
Remove the fixedSize parameter from this contructor, it's too late for that.
