dreamcat4
commented
1 year ago After @dreamcat4's recent clarification on the intention of keysReverseDirection, I am coming to think I have introduced no breaking of functionality. Rather, keysReverseDirection and modifierKeyMasksReverseDirection have not been well designed, and particularly does not fit in well now there are expose and paging mode in addition to switch
But you have introduced breaking functionality: It's a point of fact now, within the master code.
And the new modes you use to justify this false conclusion simple never existed within skippy, during those earlier time when those modifier keys handling was originally incorporated. Those were in a different era. (when skippy was broken in many other ways, for which you then absolutely fixed very well! and to your credit).
So not to downplay the value of your contributions but:
I am pretty confident that these matters about keyboard handling have nothing must (or perhaps 0) to depend upon most of the other changes you have instituted. Since picking up and improving skippy in those other ways.
Further to this point: That all these keyboard handling... it might instead be considered [in majority sense of it] as something entirely an independent feature. And literally nothing whatsoever to do with the mode invoked! Whether in fact launched as switch, expose, or the paging modes.
Regardless of the hot-key mechanism, that will intercept all Tab key events after skippy is activated. Thus, user configured keys, hot key interceptions become entangled and may lead to a messy system.
I am not so certain about the correctness of this statement.
This statement lacks some required understandings and necessary clarity about what specific assumptions you are making around global hotkey handling. But I don't wish to focus on that point!
====
What matters most (around detecting hotkeys and so on) is to think of this following corner case. As being the most difficult one. And this was the worst part at the original time, (when those hotkeys functionality was originally added):
- It was only the case of the reverse modifier key state, that (in X). That could optionally be already held (as keydown event missed)... or not held (unknown state). And this was the only so-called "crack in the gaps" because...
Back then daemon mode was not mandatory. Skippy could instead be invoked in single shot mode. Without any such background task always running.
So therefore, the keydown is missed, (within skippy, to track state). Since it's not loaded yet. Until after the global shortcut would execute a brand new instance of skippy.
So fast forwards. In out development / history. And remembering now that the main underlying reason for being introduced mandatory "daemon mode" (background task always running). Was instead for solving the longstanding iconify windows problem... to gather shapshots. Which is indeed a fantastic improvement to skippy.
So now if skippy can now be assumed to always be running in background... then can we also have skippy ensure that it always is listening to capture modifier keydown xevs (x-events)? ---> Probably "yes".
So this matter would then stand to simplify keyboard handling code. However in the current master branch, for both expose and switch modes. It seems to be something of a missing or aka "broken" functionality. Which I believe is worthwhile, and I wish to restore.
Thinking of my previous statements: that keyboard handling should have nothing much related to expose or switch (or rather boxy vs xs layout, or showalldesktops). That are the other major differentiating features of these mores (and not the keyboard handling).
And so it does indeed then returns back to same debates / refutes that the mechanism is too complex. Whether it was indeed originally poorly designed (or not, as being a subjective opinion):
I would prefer to say:
it was instead a case that a necessary level of code complexity was required to provide a necessary level of program functionality. For the program to work in a more advanced fashion. (and less 'dumb').
Or in other words the term "design" does not reflect the situation whereby the Xorg apis simply behaves in a clearly stated fashion, around keyboard / input handling (since forever). And those modifier key xevs (x-events). Then dictates the capabilities of any client x11 application to either detect, or become aware of such keyboard events.
But that was the old skippy!
If i can redesign the keyboard handling with daemon mode assumed. It may indeed simplify the program code.... i am just not so certain your commits does it. Since in my testing it simply does not seem to work here.
The observed behavior is that keysReverseDirection modifier does not work. So this matter then becomes worthy of investigation and fixings. But it's not at all agreed here by those statements you have made here today.
So those PR/MR you submitted remains into a better considered, but still a rejected state.
And again: I implore to table this specific matters. So that I can look into multi-monitor handling instead. Because that is more significant matter amongst general userbase (not for you, but for others with multiple monitors).
And please to trust that I will in fact return to this matter. At a later time. With regards to fixing / improving keyboard handling. My gratitudes.
felixfung
Creating new issue based on recent items:
161 #163 #166 #167
After @dreamcat4's recent clarification on the intention of
keysReverseDirection, I am coming to think I have introduced no breaking of functionality. Rather,keysReverseDirectionandmodifierKeyMasksReverseDirectionhave not been well designed, and particularly does not fit in well now there are expose and paging mode in addition to switch:Switch by nature has forward and backward directions, whereas expose and paging prefers up/down/left/right, and next/prev are optional. Switch also starts at next window, although switch-prev doesn't necessarily have to start on the previous window, indeed right now the behaviour is to start on current window. As @dreamcat4 noted, switch also need up/down/left/right occasionally.
It may well be desirable to many users/environments (e.g. XFCE) to map Alt-Tab to switch. Regardless of the hot-key mechanism, that will intercept all
Tabkey events after skippy is activated. Thus, user configured keys, hot key interceptions become entangled and may lead to a messy system.Now we add in addition, only within switch, but not in expose and paging, a reverse mask modifier
Shiftkey. (Expose and paging is mostly up/down/left/right, but next/prev may usenpor user configured keys) Having a direct command line optionskippy-xd --switch-previs advantageous because that allows hot key invocation starting on current or previous window, as opposed to starting on next window and then reversing with additional key modifier.But with this we start having murky potentially environmental dependent behaviour: would the
Shiftkey be intercepted by the hot key mechanism? Skippy has no way of knowing. All these lead to many considerations, complications, difficulty by the end user in setting up the skippy config file and hot key environments.Here is my alternative, and already implemented behaviour and code path:
There is
skippy-xd --switchandskippy-xd --switch-prev. An end user maps these to Alt-Tab and Shift-Alt-Tab with any means he/she desires. Then in the config file (already as default) setskeysExitSelectOnRelease = Alt_L. That's it. Then Alt-Tab, Shift-Alt-Tab, up/down/left/right all work intuitively and maximally effectively.keysReverseDirectionandmodifierKeyMasksReverseDirection, interception from hot key mechanism, clash with keysNext/keysPrev, all these are unnecessary complications and hence lead to confusion to a user. Let's remove them with https://github.com/dreamcat4/skippy-xd/commit/0e43b8360a8bbdebaf2ad4f102210457f250256f