Petr Vorel
2016-11-19 20:44:46 UTC
Hi Thomas,
You changed alt + tab behaviour in this commit:
http://git.fluxbox.org/fluxbox.git/commit/?id=ea306493f95abd04cfa5b7653e3ad30a74b1985f
commit ea306493f95abd04cfa5b7653e3ad30a74b1985f
Author: Thomas Lübking <***@gmail.com>
Date: Thu Jun 30 22:10:29 2016 +0200
re-fix alt+tab'bing through tabbed windows
commit 98313bf broke (i'm terribly sorry) this because m_cycling_last stores
the first client in a tabgroup, thus cannot be abused for this purpose.
So we explicitly store a value and btw. do it before sending the focus,
ie. "in time" for sure instead of "for sure™"
Consider this key settings:
Mod1 Tab :NextWindow {groups} (workspace=[current]) (stuck=no) (shaded=no)
Mod1 Shift Tab :PrevWindow {groups} (workspace=[current]) (stuck=no) (shaded=no)
Mod1 Left :PrevWorkspace
Mod1 Right :NextWorkspace
Before it was possible to run alt + tab several times and then *without* releasing alt
key to just press Left/Right key to go different workspace.
Now, after applying ea306493f95abd04cfa5b7653e3ad30a74b1985f I have to *release* alt key
first to be able to using alt + Left/Right key to switch workspace. If I don't release
alt and press Left/Right key, instead of moving there is ugly screen blick.
The reason is because code for "livelocks" is detecting whether we're cycling, which I'm
doing manually.
src/FocusControl.cc:
if (client && screen && screen->focusControl().isCycling()) {
...
next->focus(); // problematic for me
Would be nice to somehow distinguish these two cases.
Kind regards,
Petr
------------------------------------------------------------------------------
You changed alt + tab behaviour in this commit:
http://git.fluxbox.org/fluxbox.git/commit/?id=ea306493f95abd04cfa5b7653e3ad30a74b1985f
commit ea306493f95abd04cfa5b7653e3ad30a74b1985f
Author: Thomas Lübking <***@gmail.com>
Date: Thu Jun 30 22:10:29 2016 +0200
re-fix alt+tab'bing through tabbed windows
commit 98313bf broke (i'm terribly sorry) this because m_cycling_last stores
the first client in a tabgroup, thus cannot be abused for this purpose.
So we explicitly store a value and btw. do it before sending the focus,
ie. "in time" for sure instead of "for sure™"
Consider this key settings:
Mod1 Tab :NextWindow {groups} (workspace=[current]) (stuck=no) (shaded=no)
Mod1 Shift Tab :PrevWindow {groups} (workspace=[current]) (stuck=no) (shaded=no)
Mod1 Left :PrevWorkspace
Mod1 Right :NextWorkspace
Before it was possible to run alt + tab several times and then *without* releasing alt
key to just press Left/Right key to go different workspace.
Now, after applying ea306493f95abd04cfa5b7653e3ad30a74b1985f I have to *release* alt key
first to be able to using alt + Left/Right key to switch workspace. If I don't release
alt and press Left/Right key, instead of moving there is ugly screen blick.
The reason is because code for "livelocks" is detecting whether we're cycling, which I'm
doing manually.
src/FocusControl.cc:
if (client && screen && screen->focusControl().isCycling()) {
...
next->focus(); // problematic for me
Would be nice to somehow distinguish these two cases.
Kind regards,
Petr
------------------------------------------------------------------------------