Implement layers

[jvasile]

Some fancy or gaming keyboards have firmware that implements layers that are somewhat akin to vim modes. They let you use key combinations to switch between keymaps for short-term use. There can be a layer for navigation, another for editing, one for a specific application, etc. My interest in xkeysnail is in implementing general-purpose layers for navigation vs editing. I'd love to have a subset of vim movement keys implemented across all my applications.

I've created this issue to gauge interest in implementing layers as a feature in xkeysnail and also to solicit views on how to code it and how to make it available to users. I'm happy to write the code, and I have some thoughts about how to structure it with the current codebase.

[joshgoebel]

@jvasile Any interest in this still?

[joshgoebel]

@jvasile Pretty sure you can do this already with just conditionals... make a few globals in your config (to manage the state) and then have keys that trigger a custom function to set those globals.

Then your keymaps/modmaps would have conditional functions that checked the global state to find out whether they were "on" or "off".

[michael-nhat]

Then your keymaps/modmaps would have conditional functions that checked the global state to find out whether they were "on" or "off".

Yes, I used to think the same, but I want more interactive shortcut. For example, I bind hjkl to a function then that function check my global "vim_mode" to send custom function or origin hjkl. But when vim_mode off, it just send key press event hjkl, not key release event. and it would lead to weird behavior in some app that need key release event.

[joshgoebel]

I bind hjkl to a function then that function check my global "vim_mode" to send custom function or origin hjkl.

Yep you can do that now... your command just needs to be a function that returns the appropriate command. See all the code for set_mark and friends - what's exactly what they do - allow you to build VIM style functionality.

But when vim_mode off, it just send key press event hjkl, not key release event. and it would lead to weird behavior in some app that need key release event.

Why? You can break X if you don't send key release events... what is your exact use case again?

[michael-nhat]

Why? You can break X if you don't send key release events... what is your exact use case again?

I mean

But when vim_mode off, it just send key press event hjkl when I press, but not fire key release event when I release that key because xkeysnail has no syntax for binding key release event

For example, sxhkd has syntax for binding key down and up event. I experiment with some keyboard library in python for listen key up event inside xkeysnail when fire up function. But it is slow and hard to implement. (sorry for my poor description about problem)

[joshgoebel]

Some better examples of when and why such a thing that might be necessary would really be helpful.

[joshgoebel]

sxhkd has syntax for binding key down and up event.

I'd wager to say we (or at least my fork) likely aims to have a bit more built-in intelligence than something like xxhkd... we make a tons of decisions about managing the keyboard state based on input to reflect what we guess is the desired output. I worry that allowing someone control of explicit downs and ups would be quite likely to just break other functionality. Currently the entire engine is designed around the opposite of this behavior.

IE, whenever combos are triggered the engine purposely LIFTS any held keys (that aren't part of those combos)... so it gets complex when you add a 2nd case.... so now there are held keys that aren't supposed to be held PLUS held keys that are supposed to be held... it sounds like a lot of added complexity to solve a niche problem.

I'd suggest hacking it on (since it's all Python) but again the design of the engine itself is kind of actively working against you. If someone was truly interested in doing all the necessary work here (for their own selves) I'd certainly be interested in seeing that code, but without a chance to have the full discussion and see an implementation it's really hard to say if this would be a good thing for most users.

[joshgoebel]

@jvasile Still love to talk with you about what is and isn't possible already if you find a moment to respond.