skippy is now "too fast" or "too effecient" to cover specific prior usecase around alt+tab keypress handling

[dreamcat4]

The observed issue was inconsistent screen "flashing" or re-invokation. If pressing alt+tab multple times.

Can you please try running with/without skippy-runner and report?

This has been tried. However it did not fully resolve my issue. Now that skippy is now more performant / effecient. Such that it becomes active and then catches modifier key release event.

On older versions of skippy

• There was a delay beween the alt+tab keydown event, (which here I also always invoked -runner shell script, incurring it's own delay).
• Then there was some delay within the runner script. Between actually invoking skippy
• Such that it was possible to release the alt mod key quickly enough before skippy un-hides, and becomes active window.
• At that point, a modifier key release event only dismisses skippy window (as a cancel). Sometimes, if it wasn't too soon after the keydown event

Today

With or without runner script:

• Skippy catches modifier key release event
  • Either on it's first invocation
  • Or once skippy is opened. Then on a successive alt+tab

This then dismisses the skippy window. Fairly reliably every time.

Maybe this is due to skippy code being improved! To handle as such higher rate keyboard events? Or could be other possible reason(s).

But either way, the solution I am proposing here:

The speculative direction would be to add (as new work) an optional timer. Which can then ignore modifier key release event for some duration (in milliseconds).

So this would be a new user configurable setting. Which then is a bit akin to like some sister capability to distinguish between "long keypress event". Is a similar general concept.

So:

Immediately after being invoked / mainwin gets mapped. And skippy is also listening eagerly for keyboard events. But then if the first key event in this sequence is a modifier key "release". It mist ignore. Until timer runs out.

Then if the user does actuate + release the alt+tab key combination "fast enough" (within the user settable timeout ms)... then it could be another place to reset the timer. And permit 'fast' alt+tab full release cycle. But as a focus-next() and without actually dismissing skippy.

This is intended possible planned feature for future work. At a later date. However the concept is not yet proven. And requires some additional works before it can be assured to be the correct way forwards.

This matter is now dis-ambiguated from the deprecation of runner script / phased removal. (and installation of runner script will be ended, and replaced by systemd unit file). As per #39

However if any objections or concerns about this new feature proposal, please comment here to raise them! To discuss more about.

However this might not be the only adequate /acceptable solution. If some other options can also be considered. However I just cannot come up with any here... At least being on some limited amount of time to dedicate to this project. The other implication is that: (for myself, it's a self-serving use case), that doing such necessary work on this feature. It may indeed be deferred / delayed by an unspecified time. Or some months to winter season. And to help permit other goals outside of skippy project.

[felixfung]

I just tried on Alt-Tab on KDE, and it works exactly the same as other environments I tested on. Exactly the same. There is no flash, no lag, no premature "completion".

Can you please share your config file?

There is a bit of contrary behaviour on Alt-Tab than that reported by you that I experience, and this is identical across all environments I tested. I have idea on root cause and how to fix/improve, but the point being I don't understand your report...

[dreamcat4]

Yes because without those delay(s) introduced by runner script. It's a matter for myself to deal with and we are out of time for such clarifications.

It would be more constructive to consider this in terms of new feature request:

• The user pressed AND RELEASES alt+tab (as quickly as possible)
• If skippy is catching the modifier key release event (in it's event loop)
• Then skippy will dissmiss immediately itself.

New feature:

• Skippy will ignore modifier key release events based on a timer timeout
• If the user fast presses AND RELEASES the alt+tab (BOTH KEYS)...
• Then skippy will not immediately dissmiss itself
• In this situation, they can still long-hold the modifier key (whilst releasing TAB)
• ... and the release of the TAB (or advance key) would not dismiss skippy [and select]
• Until the modifier key is also released (both)

So it's a convoluted behaviour. You are improving skippy for other reasons... to remove other issue around handling xevent notifications. To ensure that they are being processed. But the desired behaviour here (for this events type, keypresses) is to actually do the opposite matter.

So the concept of introduction of a timer would solve this problem. And restore a previous functionality that existed historically (in prior versions of the software). But those prior behaviour may have been due to skippy missing things. Or other changes that you may have instituted for other variety of reasons (IDK).

Anyhow the point is that I am out of time here for now. And the feature does need some further consideration. For example: if we would introduce such timer feature. Would there also be other useful (desirable) user use cases. That could be added in combination. For a better feature planning.

[dreamcat4]

Can you please share your config file?

Yes however it does not really seem so relevant here (for this matter), since my custom user config - it's almost the same as default. And hope to keep it as close as possible:

 ± diff -u0 skippy-xd.sample.rc skippy-xd.rc 
--- skippy-xd.sample.rc 2023-07-12 14:29:55.526039397 +0100
+++ skippy-xd.rc    2023-07-13 18:39:24.000000000 +0100
@@ -89 +89 @@
-exposeLayout = boxy
+exposeLayout = xd
@@ -145,4 +145,4 @@
-keysLeft = Left a
-keysRight = Right d
-keysPrev = p b
-keysNext = Tab n f
+keysLeft = a
+keysRight = d
+keysPrev = p b Left
+keysNext = Tab n f Right
@@ -153 +153 @@
-keysReverseDirection = Tab
+keysReverseDirection = Shift_L Shift_R

[felixfung]

Let me try to clarify:

Behaviour A:

The user pressed AND RELEASES alt+tab (as quickly as possible) If skippy is catching the modifier key release event (in it's event loop) Then skippy will dissmiss immediately itself.

Behaviour B:

Skippy will ignore modifier key release events based on a timer timeout If the user fast presses AND RELEASES the alt+tab (BOTH KEYS)... Then skippy will not immediately dissmiss itself In this situation, they can still long-hold the modifier key (whilst releasing TAB) ... and the release of the TAB (or advance key) would not dismiss skippy [and select] Until the modifier key is also released (both)

You are experiencing behaviour A, and you would like to implement behaviour B? Am I correct?

I am experiencing behaviour B (across all environments), and was considering that a bug/imperfection, and it was a low priority task to implement behaviour A. I had some ideas but other issues are much more pressing.

I am trying to understand why you would desire behaviour B? In Windows, Mac, UNIX world, I thought the Alt key is always supposed to be held; that is, in all these platforms, releasing Alt key would terminate window switching/selecting?

I think this setting may do what you want?

Hot key binding skippy-xd --expose to Alt-Tab

and

exposeLayout = xd
animationDuration = 0
keysNext = Tab
keysExitSelectionOnRelease = Alt_L