Power-user worried about Kinto leaking into all my configs

[joshgoebel]

Related: #694

As a power user I really worry about Kinto leaking into all my configurations. I have this same problem with my Awesome WM setup. It was already perfect because I wrote it my hand (it did not need any remapping - perhaps a few changes though)... Since running Kinto I had to create an entirely new modifier (Hyper) just to get a modifier namespace that Kinto wouldn't touch.

As a power user that's one of the biggest things I wonder if there is some way to fix long-term... to me if I start coding Kinto-rebound keys into all my configs this is BAD - it makes my configurations forever tied to Kinto.

What I really don't want to do is change my Awesome WM config to "lie" about what keys it is using because they've been globally remapped. Then I can't share my dotfiles with anyone else without making them dependent on Kinto.

It's a bit of a struggle to keep track of the indirection already inside kinto.py and I'm failing to see a way to keep it from bleeding out everywhere... do you just give up on "real" keys and just have to keep the linux<->map mapping in your head at all times?

---

I sort of get this attitude when there are existing Linux key bindings... like if I'm adding a keybinding to Sublime 4 on Linux and all the other bindings are Ctrl - I should also use Ctrl... that makes sense - and Kinto handles the abstractions to Cmd.

But if I'm writing CUSTOM configs for software that doesn't already have any strong convention and I'm wanting to share that with others - this starts to sound like a less reasonable request.

[RedBearAK]

@joshgoebel

I've had a similar concern at times about putting a lot of effort into something like the Option-key special character entry method. I know without Kinto it would require a lot of tweaking for anybody to use it. But unless you can find a way with keyszer to not need any base modifier swapping, it's kind of just the way it is, isn't it?

Besides, if you were a real power user, wouldn't you just write a processing script that de-swapped the modifier terms to create a version of each config file that would work without Kinto? 🤘😛🤘

[joshgoebel]

it's kind of just the way it is, isn't it?

I dunno,that's why I opened it as a topic. Inside of the keymapper config of course we have TONS of options... you could have some keymaps that say ignored modmaps for example. Not sure if that is a good idea or not, just saying...

But on the outside... you might be right... but that is why I was thinking if Kinto could "ignore" some apps... It's not too hard to imagine real examples of desiring this... say someone has a rocking Emacs config with 1000 keys... I'd be worried what remapping (at a high level) might do to their config - it'd be nice if they could just say:

My emacs keys are perfect, leave them alone.

And all keys intended for emacs were magically unharmed... the trick is how do you know which keys are "intended for emacs". :)

[RedBearAK]

I was noticing the other day that a lot of apps have a way of specifying the WM_CLASS when you launch them. And there are tools that can be used to change the WM_CLASS of a running app, if I remember right. If the app already has a unique WM_CLASS or you can make it have one, isn't this just a matter of adding it to a list of "apps-to-ignore" and then adding "not in apps-to-ignore" to the right places to get the modmap and keymaps to disable themselves while you're in that app?

Isn't that already kind of how it works?

define_conditional_modmap(lambda wm_class: wm_class.casefold() not in terminals,{

[joshgoebel]

Yeah, but you wouldn't want all your global desktop environment keys to break while you were using that app...