Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(input): binds not working on non-Latin layouts #813

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dvtfl
Copy link
Contributor

@dvtfl dvtfl commented Sep 4, 2024

Fixes #734.

Fallbacks KeysymHandle::raw_syms() with KeysymHandle::raw_latin_sym_or_raw_current_sym().

KeysymHandle returns typed symbols as-is. For example, if "Й" (Cyrillic letter 'Io', corresponding to "Q" on the English layout) is pressed, raw_syms() returns "Cyrillic_io". However, keybinds are usually defined as "<something>+Q" (i.e., in Latin), which causes a mismatch.

On the other hand KeysymHandle::raw_latin_sym_or_raw_current_sym() tries to return corresponding Latin key symbol.

@dvtfl dvtfl force-pushed the 734-fix-binds-on-non-latin-layouts branch from 97672a5 to 458d0bc Compare September 10, 2024 09:49
@Drakulix
Copy link
Member

I am not a huge fan of this, given I worried what else this might break.

The keybindings shouldn't use keysyms in the long run for anything but describing the keys in the user interface and use keycodes for matching them instead. That would make this change unnecessary without causing a lot of breakage (hopefully).

However I am inclined to merge workarounds in the meantime. Are you aware of any layout/shortcut-combinations this actively breaks?

KeysymHandle::raw_syms() returns typed symbols as-is. For example, if "Й"
(Cyrillic letter 'Io', corresponding to "Q" on the English layout) is
pressed, raw_syms() returns "Cyrillic_io". However, keybinds are
usually defined as "<something>+Q" (i.e., in Latin), which causes a mismatch.
@dvtfl dvtfl force-pushed the 734-fix-binds-on-non-latin-layouts branch from 458d0bc to 3206377 Compare September 11, 2024 12:43
@dvtfl
Copy link
Contributor Author

dvtfl commented Sep 11, 2024

The keybindings shouldn't use keysyms

FWIW: IIUC Windows, Gnome, KDE, i3 are using keysyms for keybindings. E.g., pressing a bind that require keys Win+[Latin Q] on English (QWERTY) layout would require pressing Ctrl+[Latin A] on French layout (AZERTY).

Are you aware of any layout/shortcut-combinations this actively breaks?

Nope.
I’ve updated the commit so that the system first attempts to match the binding with the current layout. If it fails, it falls back to matching the Latin key. This way, binds like Ctrl+é (french layout) shouldn't break (at least i hope, it's getting confusing for me).

@Drakulix
Copy link
Member

FWIW: IIUC Windows, Gnome, KDE, i3 are using keysyms for keybindings. E.g., pressing a bind that require keys Win+[Latin Q] on English (QWERTY) layout would require pressing Ctrl+[Latin A] on French layout (AZERTY).

Good to know.

Nope. I’ve updated the commit so that the system first attempts to match the binding with the current layout. If it fails, it falls back to matching the Latin key. This way, binds like Ctrl+é (french layout) shouldn't break (at least i hope, it's getting confusing for me).

This seems like a good change, however this still means we go through all bindings in order and potentially select a weaker raw_latin_sym_or_raw_current_sym-bind, although later in our loop a binding could match a raw_syms-bind...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Changing language messes up binds
2 participants