* ClientPattern.cc: make compiler happy (complaints about XPROP not handled in switch)
* FbTk/FbPixmap.cc FbTk/StringUtil.cc: signed vs unsigned
* FbTk/FbString.cc: missing return
* WinClient.cc: create atoms only once; use helper function
* Window.cc: use a helper function
for each window (windows, menue etc) the initCorners() function of
FbTk/Shape.cc was called (which is ok). On each call the corner pixmaps
(of the Screen the window belongs to) were created and destroyed the
formerly created pixmaps. this is not needed.
the global 's_corners' vector was still used on an application shutdown
(including ctrl-c SIGINT). depending on when 's_corners' was created on
the stack this could lead to an exception ('pure virtual called') while
trying to free the 'FbPixmaps' without having a valid
'FbTk::Application::instance()' left.
our users should migrate seamlessly to our new windows-cycling behaviour
without losing their current way of doing things. so, 'fluxbox-update_configs'
tries its best to add '(workspace=[current])' wherever it looks like a valid
place for it. such changed lines are marked by '!! FBCV13' at the end and can
be easily spotted in case the updater got it wrong.
addtional changes:
* added '-check' to 'fluxbox-update_configs' to check the version number in
'~/.fluxbox/init' vs. the version number of 'fluxbox-update_configs'
* moved the update-code for each version into its own function, easier
housekeeping
commit 882a50fe1d removed the hardcoded limit to
cycle to windows on other workspaces, though it was and IS a good default
behaviour. if users do not want this (they want to cycle to windows on other
workspaces), they should explicitly avoid '(workspace=[current])' in their
keysfile.
these two allow 'tagging' of arbitrary windows with 'tags' (or 'labels'). such 'tagged' windows can then be used in ':NextWindow (@PROP=foo)' commands to quickly cycle through a subset of available windows.
since the 'tags' are applied as real xproperties to a window they survive a restart of fluxbox or even another windowmanager. the user can also set the tags by using xprop(1).
the next step regarding the UI should be to visualize the tags of a window.
reasons:
* fixes#1732115, allows to have chatwindows on another workspaces and reach them via :NextWindow (urgent=yes)
* old behavior can be achieve by using the (workspace=[current]) pattern
a 'BidiString' holds both the logical content and the visual reordered
version of the content of a string. this helps to reduce the number of
calls to reorder the string before drawing it (as introduced in the patch
from Ken Bloom) and to be more consistent in menus and textboxes (drawing
cursors and underlining text).
* parse the string only once for a bunch of chars to check instead of
starting over again and again from the beginning, created a helper
function to do this (FbTk::StringUtil::findCharFromAlphabetAfterTrigger)
* put same code into a function (setClockModeLabel())
* use much simpler code to switch between 12h and 24h mode and replace
the fmt-switches
