jtroo / kanata

Improve keyboard comfort and usability with advanced customization
GNU Lesser General Public License v3.0
3.22k stars 131 forks source link

Feature request: one-shot timeout action #970

Open oblitzitate opened 7 months ago

oblitzitate commented 7 months ago

Is your feature request related to a problem? Please describe.

When I tap a one-shot key, I want to be able to run an action like a cmd after timeout (if no further key has been pressed) so I can do things like a deadman's switch or notify that a modifier key has 'unstickied', etc.

Describe the solution you'd like.

It could look: (one-shot-press-timeout <timeout value> <one-shot action> <timeout action>)

Describe alternatives you've considered.

A workaround seems to be using virtual keys like so: (multi (on-release tap-vkey some-one-shot-vkey) (on-idle 1 tap-vkey some-cmd-vkey))

Additional context

If the above feature request is approved, maybe also allow a pre one-shot action so I could run a script immediately just before a one-shot action.

jtroo commented 7 months ago

one-shot timeout action

Maybe this works: simulator. Here z takes the placeholder of cmd because cmd isn't allowed in the simulator.

allow a pre one-shot action

I think this is possible today: simulator. The mlft takes the place of the pre-action here.

I haven't fully dug into why but seems some indirection/delay is needed to avoid an early trigger of the one-shot release. It's a bit clunky but seems to work.

jtroo commented 7 months ago

Describe alternatives you've considered.

A workaround seems to be using virtual keys like so: (multi (on-release tap-vkey some-one-shot-vkey) (on-idle 1 tap-vkey some-cmd-vkey))

Out of curiousity does this actually work how you want it to? It would unconditionally execute some-cmd-vkey.

jtroo commented 7 months ago

Maybe this works: simulator

A weakness in this solution is that I don't think it works quite right if you double-tap the one-shot key. But maybe some extra logic in the switch can make it work how you would expect in that scenario.

oblitzitate commented 7 months ago

Describe alternatives you've considered. A workaround seems to be using virtual keys like so: (multi (on-release tap-vkey some-one-shot-vkey) (on-idle 1 tap-vkey some-cmd-vkey))

Out of curiousity does this actually work how you want it to? It would unconditionally execute some-cmd-vkey.

Not exactly, but I don't need it to be conditional for my current config right now.

Maybe this works: simulator. Here z takes the placeholder of cmd because cmd isn't allowed in the simulator.

Interesting idea! I should probably play around more with switch and input-history and what not.

oblitzitate commented 7 months ago

In switch, I felt key-timing worked better than input-history, at least for my use case.

Anyways, thanks to your solutions, I can run a pre-one-shot action and post-one-shot timeout action, which is great.

However, is there a good solution to run a post-one-shot action after a follow up key has been pressed (without having to modify each key in the one-shot's layer-while-held)?

jtroo commented 7 months ago

Debateable if it's a "good" solution, but with some hackery with tap-hold-press-timeout, it can work: sample

I used switch as a weird-looking multi using fallthrough because it behaves slightly differently; the actions activate one tick apart.

The tap-hold-press-timeout's hold activation interrupts the one-shot action, so the hold action needs to persist the one-shot action itself, for a little while longer while b activates, and then the hold action releases itself earlier than the deadmanswitch releases it.