When remaping Super+key it opens application menu like when Super is pressed after remapped combination

[nrsimha]

I am using following code to remap Super+C to Shift+Control+c in Konsole. It works, but after remap command it also opens application menu like if I would press Super, which is doesn't suppose to.

define_keymap(re.compile("konsole", re.IGNORECASE),{
    K("LSuper-C") : K("LShift-LC-C"),
    K("LSuper-V") : K("LShift-LC-V"),
}, "Konsole copy paste")

[masutaka]

You may have assigned the Ctrl-Esc key to the application menu in your window manager.

[nrsimha]

I have there Alt+F1, when I remove it, Super+C and Super+V works nicely, but then I cannot open Application menu with Super key alone.

What is interesting is that if I press some other Super+letter which is not remaped in xkeysnail it doesn't open application menu. Application menu is opened only after using those remapped combos.

[joshgoebel]

@rbreaves This is really the same as the Alt issue... have you given it much thought? I'm working on it now and trying to decide the nuances... I'm calling it suspend and resume, let me give you an example... (try and forget about sticky keys for a moment)

I'm going to hit Super-Tab... with a mapping to RC-Tab... So here is the sequence of events:

• I hit Super.
• Since the state is "clean" (there are no held keys) output is suspended for 0.5 seconds
• I hit Tab.
• The engine sees that tab is part of the Super-Tab combo and fires that.
• RIGHT_CTRL is PRESSED on output.
• TAB is PRESSED on output
• TAB is RELEASED on output
• RIGHT_CTRL is RELEASED on output.
• Super is marked as "quiet release" allowing us to lift it (and set it's state to unpressed in the transform layer) without triggering a resume

Notice that we've never registered SUPER on the output at all... (vs 0.4 which would have immediately registered it - then lifted it before the combo, then reasserted it immediately after the combo).

Now at this point one of two things can happen.

• Super is released before the resume timer fires.
• Super continues to be held.

If super is released, it's done so "silently" which means that either resume is cancelled or that when it finally fires there are no keys to send to output - so as far as output is concerned super was never pressed (which is correct - since it was remapped). You can see already this is a huge step up from 0.4.

If super is still held then when the resume timer fires Super will FINALLY be asserted on the output as an actual keypress.

---

Now this seems fine unless ones goal is to use Super to trigger a BUNCH of macros... one after another... so I'm starting to think that each time a combo is fired the resume timer should be pushed out into the future further... such that I could fire 4-5 macros in sequence and as long as I was firing them every 0.5 seconds then real keys would never exert themselves on output at all.

The alternative is to have a static timer, but I think that will break combos when the Super key finally re-asserts itself...

---

And of course auto-resume would happen as necessary...

• if we pressed then rapidly released Super then a resume would happen sending both those keystrokes to the output.
• If we hit a non-modifier (that isn't a combo) then we resume before sending that key so that if it's a native combo it works properly

Basically the idea of suspend is to "suspend" keys inside the transform layer until we understand their purpose - and prevent sending them to the output at all if their only usage was to trigger macros.

Any thoughts/questions? Next I have to fully flesh out sticky as it would probably get caught up in this new suspend/resume system.

[joshgoebel]

I feel like if my fork could resolve both the sticky issue and the unwanted keys issue that would be a good first release.

[joshgoebel]

Note: It's also possible the timer could be infinite, but that would prevent using a single held modifier as a trigger for anything... For example:

• I press and hold Super.

It's possible some software could care about that and if we just suspended it forever (waiting for more keys) then that software would never see super at all.

[joshgoebel]

@nrsimha If you'd want to join the new discussion on this issue at my fork (where I've been trying to fix this):

https://github.com/joshgoebel/keyszer/issues/9

I'd truly like to fix this, but turns out it's a hard problem. Your feedback might be helpful. Please see issue 9 and at least read the recent update, which is a summary. Then if you have any thoughts please share.