Age | Commit message (Collapse) | Author | Files | Lines |
|
m_client.focus(), closes #3210493
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.
|
|
|
|
use the FbTk::Timer API correctly, bug(s) introduced by
1f0adef4daa2da5b08ed7f41e7a0ce1e3f71e46f
e68511794130388ab9668fdef0dcf48dbbf002fd
|
|
|
|
see #3088856 / 09f99a4674a75a201effdc912d79a28c2dad4225.
at the moment this fix looks side-effect free, time will tell.
|
|
workspace, see #3088856
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.
|
|
|
|
had to add <algorithm> at various other files as a result of this change.
|
|
|
|
|
|
|
|
|
|
|
|
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'.
|
|
|
|
|
|
|
|
|
|
At least 'invertRGB()' does not like 'width' or 'height' being 0.
341b2f43e511e39dd was triggered by this problem as well.
|
|
|
|
With ROT90-SystemTray fluxbox crashed. It is a bit unclear of where
to catch pixmaps / windows with either width or height equal to 0; IMHO
this needs more investigation.
|
|
|
|
|
|
|
|
nxserver-3.x creates a XExposeEvent for the unmapped FbTk::Menu(), which is
not configured completely yet (hence unmapped). this causes a call to
FbTk::Menu::clearItem() which then uses a value of 0 for m_rows_per_column
to divide the current index which triggers a SIGFPE.
it is still unclear, why nxserver-3.x creates the XExposeEvent for the
unmapped (menu) window. doing nothing if the menu is unmapped 'fixes'
the problem for now.
many thanks to Lars Engels (bsd-geek.de) to assist me in debugging this
issue.
|
|
|
|
'typeinfo' was needed for RTTI in isItemSelectable() (see last commit)
'algorithm' is already included some lines above
|
|
|
|
MenuSeparator is never enabled since it returns always 'false' in its
implementation of isEnabled(). no need to use RTTI imho.
|
|
* removed useless struct _menu
* code deduplication via renderMenuPixmap()
* improved documentation:
- 'sublevel' actually means 'column'
- 'persub' means 'row_per_column'
|
|
--disable-toolbar
|
|
a newer xlib recently changed the result of 'DisplayString()' a little bit:
instead of returning ':0.0' or ':1.0' it yields ':0' or ':1'. our code to
transform this string into something that includes the currently used
Screen worked only on something like ':0.0'.
we now find the '.' after the ':' and strip that part away.
|
|
not having DISPLAY set (eg: on a headless system) caused fluxbox to crash.
|
|
by using FbCommands::ExecureCmd() we run 'fluxbox-update_configs' in
the bacground while booting a new fluxbox instance already. 'system()'
waits until 'fluxbox-update_configs' is done and then gives the control
back to fluxbox.
|
|
|
|
while integrating the old 'getSqrt()' function into the 'bsqrt()'
function i misplaced some code. this lead to 'r' being 0 on the
first run. doh.
|
|
|
|
before bringing up the first instance of Fluxbox we prepare the directory
and the files it needs. if the config version of exiting files is lower
than what we expect, we upgrade the config files. after that we bring
up Fluxbox.
the old way was problematic because setupConfigFiles() calls
'fluxbox-update_configs' which does its job in the background while
fluxbox continues to boot. 'fluxbox-update_configs' sends a USR2 signal
to the booting fluxbox (it might even be finished, no one knows) which
triggers 'load_rc()' which triggered 'setupConfigFiles()' again which
might trigger 'fluxbox-update_configs' again (on my machine
'fluxbox-update_configs' was called 3 times and left a pretty crippled
'keys' file when it was done).
bootstrapping before bringing up fluxbox resolves the issue. as a bonus:
no need to send USR2 to fluxbox to reload the config file because fluxbox
has not even tried to read it yet.
|
|
|
|
got lost in d3eabeb805fdbd162c0743ed86a67e014e37c097 somehow
|