Investigate: houmain/keymapper

[canadaduane]

I like several things about this software, keymapper: https://github.com/houmain/keymapper/

1. The syntax for simultaneous keypresses is quite intuitive, e.g. (A B), as is the syntax for press-and-hold plus another key, e.g. Meta{X}
2. The configuration files for app-specific key mappings is similar to keyd, but I like the specificity of params:

[default]
CapsLock >> Backspace

[title="Visual Studio"]
Control{B} >> (Shift Control){B}

[system="Linux" class="qtcreator"]
...

[system="Windows" title="..." class="..."]
...

Regular expressions:

[title=/Visual Studio Code|Code OSS/i]
...

In our case, we don't support alternative systems (such as Windows) but some desktop managers (X, Gnome, Sway) may report window values differently, and so it might be useful to offer filters for each of the DMs.

Anyway, it's neat to see how others have sliced the problem and maybe imitate (with credit, of course) what works well.

[rvaiya]

I like several things about this software, keymapper: https://github.com/houmain/keymapper/ The syntax for simultaneous keypresses is quite intuitive, e.g. (A B), as is the syntax for press-and-hold plus another key, e.g. Meta{X}

Thanks. This indeed looks like an interesting project, though I daresay it looks like what one would expect if keyd was designed by a c++ programmer ;).

One of the design goals of keyd is to make easy things easy and hard things possible using simple set of expressive primitives.

For example, holding multiple keys for layer actuation can be achieved by nesting layers like so:

[alt]

shift = layer(alt_shift)

[shift]

alt = layer(alt_shift)

[alt_shift]
....

while it would be possible to introduce a bunch of syntactic sugar to autovivify and set up layers, I am generally opposed to this unless it adds some useful functionality.

Forcing the user to explicitly define layers is a feature, not a bug, since it gives them a conceptual framework to understand how changes apply to the keymap and causes them to reason about edge cases.

The one thing which is currently not possible to achieve using this setup is time based detection of related keys. I have been toying with the idea of adding such a feature using similar synax (e.g a+b = layer(c)), but have mixed feeling about it. The best place to discuss features like these is in a dedicated issue. Feel free to create one if you think something is a good candidate for inclusion.

(X, Gnome, Sway) may report window values differently, and so it might be useful to offer filters for each of the DMs.

Users will use the output of the script to discover valid names anyway, so this isn't an issue. Having said that, I believe app ids are usually identical to window class names in practice (there is a 1->1 mapping for X clients).

[canadaduane]

Users will use the output of the script to discover valid names anyway, so this isn't an issue.

My glorious master plan is to build an easy one-step deb package that enables "meta-mac mode". In that scenario, users would hopefully not be toying with wm_classes and wm_names. But it's good to hear that they are 1->1 with X clients in practice.

[rvaiya]

Given that many of the bindings will necessarily be DE specific, you are probably going to end up targeting a single platform (i.e Gnome) anyway unless you get into the business of modifying sway configs and the like on the fly.

But it's good to hear that they are 1->1 with X clients in practice.

I believe this is true :P. To my knowledge app ids for legacy clients are drawn directly from WM_CLASS. Native clients are of course free to set the app id to whatever they want, but in practice this seems to correspond to the old X class name, and I see no reason why an app would deviate from this.

If you encounter any discrepancies I am happy to include a normalization map in the remapping script to provide uniformity.

[canadaduane]

Given that many of the bindings will necessarily be DE specific, you are probably going to end up targeting a single platform (i.e Gnome) anyway unless you get into the business of modifying sway configs and the like on the fly.

Yes, perhaps so. I was considering the possibility that I could create a config similar to houmain/keymapper that would allow me to target quirks of each DE if needed. For example:

[desktop="sway" class="alacritty"]
# sway-specific bindings for alacritty

[desktop="x" class="alacritty"]
# x-specific bindings for alacritty

This is all hand-wavy at this point though, because I don't have an actual example of a difference between the two to point at.

If you encounter any discrepancies I am happy to include a normalization map in the remapping script to provide uniformity.

I'll keep that in mind, thanks!

[rvaiya]

In true YagNi spirit I prefer to let necessity be the mother of invention ;). I am closing this for now, but feel free to open another issue if you encounter a problem with the current implementation.