Question: Plain key remapping (without modifiers)

[joshgoebel]

@luizoti @rbreaves

Is anyone using the library for that that you're aware of? IE, to remap QWERTY to DVORAK or something weird...

Or if so could we consider that an edge case? Right now just to type a single character (like "d") with no keymapping at all requires a TON of work, finding keymaps, talking to the window manager, etc... it pegs my CPU at 15% just to hold down a key... (I have fast repeats)

It seems perhaps if no modifier is held we could just pass the keys straight thru to the output without all that effort for a much smoother pipeline?

[luizoti]

The only mention of dvorak from what I saw is in this PR, for me it is an extreme case yes.

Do you want to remove modifiers or change how they are identified?

[joshgoebel]

Do you want to remove modifiers or change how they are identified?

Removing modifiers? huh? I was just talking about trying to speed up the "someone is typing a sentence of text" pipeline... so I think transform_key should terminate VERY, very fast when there is nothing to transform... ie, if no modifiers are being held...

It's possible we may still need to deal with escape_next_key, I'm not 100% sure what that is used for yet.

The less Python can we can have running per keypress the less likely bugs are as well. I'm not usually a performance over optimizer but when we're running slow/interpretted code for every single keystroke it seems perhaps we should focus on that - and long term it'd be nice to have benchmarks...

[luizoti]

Hmm, I think I got it wrong, yes I think it's a great idea to optimize the performance, being possible to pass common keys directly as you said, I think it's a good way.

Regarding escape_next_key, I also have no idea what the purpose is, a lot has been included by several people (and I include myself, but in my repo) and a lot was not clear about the usefulness.

Considering a refactoring, wouldn't starting from a base with a minimum of functions, cutting current functions, and reinserting them over time be a good way to go?

[joshgoebel]

Well, I assume if functionality exists they are being used by someone, so I'd rather understand their purpose, then add tests for them, etc... tests are the thing we need the most. :)

[luizoti]

I agree, if there is, some use it, but the idea is not to remove the functions, what I'm asking is if n would be better to refactor, and to add it little by little, instead of refactoring and putting it all at once, I say this because some methods may be able to be merged and still retain the same functionality.

Anyway, you have more experience and can suggest a viable and healthy way to rewrite the project (if rewriting is your idea, of course).

[rbreaves]

it pegs my CPU at 15% just to hold down a key... (I have fast repeats)

Interesting, I’ve not looked that closely to see the cpu usage. I originally wrote an app in C to use xkbmap until I realized xkeysnail was equally responsive, easier to work w/ & more flexible.

Unit tests would be good - I've not been consistent in writing them or good about it but I know it’s just a matter of changing my thinking before I write my code.

[joshgoebel]

Interesting, I’ve not looked that closely to see the cpu usage.

Well, it was also scrolling the terminal window, so that counts for some of that. :-) But to me this is almost a "kernel level" kind of thing... if we stick with Python then our goal should make it as optimized as possible (without sacrificing readability)... and I see all sorts of opportunities for improvement in that regard... there is lots of O(n) or O(n^2) code here that could be simplified to O(1)...

[joshgoebel]

Interesting, I’ve not looked that closely to see the cpu usage.

I think checking the X context is a large part of it... in some actual stats I did adding a "pass thru" for plain text (a-z) when no keys are pressed the difference was:

• 1500us-2000us for running thru the whole stack
• 150-200us for short-circuit for QWERTY

So an order of magnitude difference. I mean 1.5ms isn't exactly slow in the grand scheme of things, but for a keypress (which should be almost instant) that's forever IMHO. :-)