biggest change: renaming of 'class Layer' to 'class ResourceLayer' in
Layer.hh to handle complaints about 'ambiguous Layer: Layer or FbTk::Layer'.
'ResourceLayer' sounds crappy, but that was the best I could come
up with right now.
changing the layout or the number of the attached monitors
might lead to invisible windows. only those windows should be
positioned to the closest monitor, if they are not visible
already.
m_client.focus() might call ~ClientMenuItem(), thus m_client is not available anymore. the crash was triggered by trying to deiconify a client via the clientmenu. this triggers a signal to remove and destroy the current ClientMenuItem.
warping a transient window to the next workspace creates a cycle between
BScreen::changeWorkspaceID(), BScreen::reassociateWindow(), Workspace::removeWindow(),
FocusControl::unfocusWindow(), FluxboxWindow::setCurrentClient(), FluxboxWindow::focus()
and so on.
for now we just stop allowing transient windows to be warped, it is most
likely a bad idea anyway having the modal dialog on one workspace and the
(dead) main window on another one.
this issue must be analyzed further, since there might be a deeper problem
with the way the focus code works.
FbTk::Menu::updateMenu() recalculates the width() and height() of the
window. this must be done before the menu is moved to fit completely
onto the screen.
the 'menu().raise()' command is not needed, that is done inside
'menu().show()' already.
The issue was caused by a client that got an unmap notify and had a FocusIn event
directly after in the event queue. The focus in event was handled by Fluxbox::revertFocus
before the WinClient.cc removed itself from the search window list.
WindowMenuAccessor returned strange alpha values if compiled
with 'g++ -Os'; unholy black magic happens if template<int> faces
functions returning only 'usigned char'.
