* 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.
- When the target address of the memory view changes, an attached
listener is now notified. This lets the inspector window's text input
keep in sync with the current address when keyboard navigating the
memory view.
The syscall might be interrupted, especially in signal heavy
applications. In that case we need to retry the read until the timeout
runs out. since the timeout is already absolute we don't need to adjust
anything.
