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.
Since for image/file paths, the most interesting part is generally the
filename at the end, and the initial path information is mostly
redundant, it makes more sense to truncate at the beginning.
In some cases, BStringColumn wouldn't properly detect that an update was
needed, and would consequently fail to truncate a string as needed with
a column resize.
* similar to what mmlr did in hrev45575 for bfs.
* DirectoryIterator could try to read past the end of the directory.
* replaced a dprintf with a TRACE() statement.
