Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
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 882a50fe1d4930b156965c54d9b66ecb27b4c9b2 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.
|
|
|
|
* moved code from public API to internals
* avoid code duplication ( while(!m_terms.empty()) ...)
* cosmetic '(*it)->' vs 'term.'
|
|
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
|
|
|
|
|
|
|
|
on startup a lot of 'Fluxbox: X Error: BadDrawable (invalid Pixmap ...)' occured.
this was caused by using an empty 'Window' to create the shape.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
removed obsolete 'getuint()' function
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
expressions'
|
|
|
|
|
|
|
|
|
|
|
|
While 769130f51a8f did fix one issue, it introduced another by changing the
logic related to the new SignalTracker. The original logic (introduced in
9ad388c5bf16) was:
-> in 'leave(Signal)', only call 'disconnect'
-> in 'leaveAll()', call 'disconnect' and 'disconnectTracker'
But 769130f51a8f inverted this, calling 'disconnectTracker' in both cases but
only 'disconnect' in the 'leaveAll()' case, which would leave unattached signals
around after calling 'leave(Signal)'.
This fix not only repairs the logic, but renames the ambiguous 'disconnect'
boolean to something more explicit: 'withTracker'.
|
|
As noted in the previous commit, StrictMouseFocus now works as advertised:
Focus follows mouse on every EnterNotify event (except when the "ClientMenu"
closes or during alt+tab window cycling)
|
|
This is not actually implemented yet, but from now on, "MouseFocus" means:
Focus follows mouse only when you are moving the mouse, any EnterNotify events
caused by non-mouse operations (window closing, keycommands, changing
desktops) will *not* shift focus
And once fully-implemented, "StrictMouseFocus" will mean:
Focus follows mouse on every EnterNotify event (except when the "ClientMenu"
closes or during alt+tab window cycling)
|
|
gets destroyed
|
|
reordering of Resource-related stuff was because of
"error: explicit specialization of 'getString' after instantiation"
complaints.
|
|
|
|
class
|