Rework sticky mods

[kareltucek]

Closes UltimateHackingKeyboard/firmware#953.

Testing:

Sticky and nonsticky (both macro and native) shortcuts bound in both base and mod layers:

holdKey LS-q

holdKey sLS-q

Furthermore, for sake of completeness, the same four bindings bound in caret mode, and again tested in both base and mod layers:

set module.touchpad.navigationMode.base caret
set module.touchpad.navigationMode.mod caret

set module.touchpad.caretAxisLock 1

set navigationModeAction.caret.left keystroke LA-tab
set navigationModeAction.caret.right keystroke LS-q
set navigationModeAction.caret.up macro tstStickQ
set navigationModeAction.caret.down macro tstNonStickQ

set keystrokeDelay 30

[kareltucek]

Hmmmm, although to be fair I am not at all sure whether by specification sticky keys from macros should or should not stick in the base layer.

Is anyone using such bindings in their workflow and have an opinion on it?

[mondalaci]

Sticky as with Alt-Tab? If so, I can't see how sticky would make sense on the base layer. Feel free to make an example.

[kareltucek]

I don't see that either, but thats a fact of the state of my mind, not of the state of the world 🤷.

We are talking about macros where the user has explicitly asked for the shortcut to be sticky, so who are we to question that?

On the flip side, these mapping do exist in layers that can be either held or toggled, so it is reasonable for the user tocexpect that they will stick when held and not stick when im base layer.

I.e., I would really like to hear an opinion from @mhantsch and @rpnfan , and possibly others.

[kareltucek]

Also, not to go too far, alt tab is a totally legit example - you may want to switch windows without having to hold another key.

[mondalaci]

I've merged this PR because the fix works according to feedback. Feel free to continue this conversation regardless.

[mhantsch]

I would really like to hear an opinion from @mhantsch and @rpnfan , and possibly others.

Well, I might not completely understand which part you are unsure about.

Keeping a mod sticky on the base layer? How should that work, i.e. when would it be released eventually? If I let go of all the keys, I'm not holding anything anymore. I think then everything should be released. If I still wanted to forcibly keep something pressed in this case, I would have to write a smart macro that keeps those keys depressed. That's a very sophisticated use case then. Nothing the ordinary user will need. (I might 😏 )

So what would be the use case for Alt-Tab on the base layer? It would just switch to the next window, and release Alt. Can't be sticky.

I don't see any other "sticky" use cases that I would need, so I think the behaviour is working fine now.

[kareltucek]

The alt tab would be tap it three times to get to the third window (alt has to stick for this to work). Next uhk action will unstick it again, so if you wanted to just release the alt, you could just tap escape.

[mhantsch]

I mean the only use case I could think of (in the weirdest part of my brain) is this:

set navigationModeAction.caret.left macro window-forward
set navigationModeAction.caret.right macro window-backward

(Caret is configured for Fn layer)

window-forward:

tapKey sLA-tab

window-backward:

tapKey sLALS-tab

Now I would want Fn + left/right movement to pop up the Window selector and scroll left/right through it, until I let go of the Fn key. But that doesn't work. Currently, it just hops to the next window and the pop-up never pops up. (At least here under Pop_OS! 22.04 / Gnome / Wayland.)

[mhantsch]

The alt tab would be tap it three times to get to the third window (alt has to stick for this to work). Next uhk action will unstick it again, so if you wanted to just release the alt, you could just tap escape.

I would argue that this "next tap on any key including Escape activates the window selection" is against any reasonable UI design (tap Escape to actually ACTIVATE the selection??). So I don't think this use case needs to be supported. :)

[kareltucek]

Allright!

[mhantsch]

Now I would want Fn + left/right movement to pop up the Window selector and scroll left/right through it, until I let go of the Fn key. But that doesn't work.

Also I haven't tested whether this works with an UHK60 and the old firmware. (I don't think so.)

I think if you can make the UHK80 firmware handle sticky mods the same way as the previous UHK60 firmware, then it would be good enough for a first release.

[kareltucek]

Don't they now?

[mhantsch]

Yes, I think the mods now work the same as UHK60. I wouldn't change anything anymore. All my use cases work (but I never did anything fancy with sticky mods; I just use Alt-Tab).

[rpnfan]

I see you had a good discussion. :-) I do not have to add something from my side.