This is the developer of skippy-xd, which has been under active development with many new features in https://github.com/felixfung/skippy-xd!
Youtube demos are here:https://www.youtube.com/watch?v=R__zua04xe0https://www.youtube.com/watch?v=reUDapFGnmQhttps://www.youtube.com/watch?v=lS33Z2s8xrs
I would like to ask about different Unix/Linux solutions and mechanisms to keys binding, key holding and key detection.
Skippy-xd always has Alt-Tab solution, and can do the same for expose like modes. It is set up by the user using xbindkey or similar to bind to skippy-xd --switch --next, and then setting Alt as a pivot key. When skippy-xd is being activated, it detects whether the pivot key is being held; when the pivot key is not being held, skippy-xd deactivates and selects the focused window.
https://youtu.be/lS33Z2s8xrs?si=wkGJ0sqGrFTwwXVa&t=459
Recently, I realized the design/implementation was not complete: a user should be able to designate a pivot key (for example F11 or Super/Meta key, or even the new copilot key...) for expose and use it without a next command. The usage would be when the user press and hold F11/Super, the user can select with mouse and/or up/down/left/right, and when the user releases, skippy-xd would terminate and select the focused window.
I have implemented this successfully, except when the pivot key is set and held, other keys, including up/down/left/right, would not be registered. Here is where I would like to ask about Unix/Linux keys.
When I test with xev (without any hot keys set), holding F11 and after a delay hold n, it would first show rapid alternate KeyPress and KeyRelease events for F11, and then when n is pressed, KeyPress and KeyRelease events for n would register. Hence, I think in general, holding a key would not block pressing/holding another one.
However, when I debug the source code of skippy-xd,
while ((num_events = XEventsQueued(ps->dpy, QueuedAfterReading))){ // the while loop and XNextEvent() are existing code for event detection XNextEvent(ps->dpy, &ev); // this is for debugging purpose, to see if X events are detected at all if (ev.type == KeyPress || ev.type == KeyRelease) { XKeyEvent * const evk = &ev.xkey; printfdf(true, "(): KeyPress | KeyRelease, keycode: %d:", evk->keycode); } // ...When I set up with pivot key F11, use xbindkeys to bind F11 with skippy-xd --expose, and hold F11 to activate skippy-xd, and then tap/hold n, no logging will be produced. This is in contrast with when I don't set pivot key with F11, and do not bind F11 with skippy-xd --expose, when I activate skippy-xd, then hold F11, and then tap/hold n, logging of the key press and key release events are produced.
I interpret this as strange combinations/interference between the X key registration, key bindings, and even window focus state, although I am not certain.
I would like to ask what exactly is happening in terms of X key events, and what solutions for app key binding and coding key detection would be possible?
Thanks.
Update:
Mouse selection has always been working in this "pivot mode". I have verified X event registration on this:
if (mw && MotionNotify == ev.type) { // print to verify X event is registered printfdf(true, "(): !!!"); // when mouse move within a client window, focus on it // ...Hence the issue is not that the event is not detected due to short-circuited event detection loop, but most probably that the keyboard event(s) were never registered in the first place, indicating the root cause of the issue is related to X key binding.
Any help would be appreciated. Thanks!