Changed alt+tab behaviour

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 <[email protected]>
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

------------------------------------------------------------------------------
_______________________________________________
Fluxbox-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fluxbox-users