asbru-cm / asbru-cm

Ásbrú Connection Manager is a user interface that helps organizing remote terminal sessions and automating repetitive tasks.
https://www.asbru-cm.net/
GNU General Public License v3.0
971 stars 132 forks source link

Keyboard shortcuts do not work in non-Latin layouts #1091

Open vanchelosa opened 4 months ago

vanchelosa commented 4 months ago

Keyboard shortcuts do not work in non-Latin layouts.

ctrl+c, ctrl+v, ctrl+shift+c, etc. do not work if the layout is not Latin. That is, if a non-English layout is currently selected, then to copy and paste the text, you need to switch the layout to English. Spoils life.

The problem is known and old, but of all the applications, asbru is the only one in which this has not been solved, in all others this behavior has not been seen for a very long time.

Fedora 38, Gnome.

gfrenoy commented 1 month ago

What do you mean with "non-English" layout ? Keyboard layout ? How do you switch the layout to English ?

I'm definitely not using an English keyboard layout and all keyboard shortcuts are working fine so you'll need to be a bit more accurate so that we can improve this...

vanchelosa commented 1 month ago

Yes, I mean the keyboard layout. In my case, I have English and Russian layouts. When the English layout is selected, the hotkeys work, when the Russian one is not. I can't figure out how to explain it... in general, if you select a combination in English in the hotkey settings, then it will be like this:

2024-08-16-08-51

And if in the Russian layout, then it will be like this:

2024-08-16-08-52

That is, the keyboard shortcuts are different. I have only two examples with this behavior - vim and asbru-cm, the rest of the applications work correctly.

gfrenoy commented 1 month ago

First, apologies for not being comfortable with Cyrillic languages, this is very new for me but very interesting topic to investigate so thanks for bringing this to my attention :)

So I made some experiments and setup a VM with a similar configuration as yours : two keyboard layouts configured, one in a Latin-language and another other with a Russian layout (the very standard one).

What I observe, indeed is:

So my conclusion at this stage of the investigations is that we don't store the key definition the right way. I mean, the "internal code" of the pressed key is probably always the same but what we see (the "human readable" pressed key) must depend on the keyboard settings.

If someone has some interest to continue the investigations, what I suspect is that, in PACKeyBindings.pm, we have to use the "hardware_keycode" (see EventKey) which remains the same, whatever the keyboard layout. A deep re-engineering of PACKeyBindings will be required, not a trivial one, I do fear :worried: