yue-dongchen/qsfnql

QWERTY Shortcuts for Non-QWERTY Layouts

qsfnql's Issues

Create “known problems” documentation; possibly report to Chromium

This in an inherent problem of Chromium in Linux with mappings done in the XKB approach. AFAIK it's isolated to Chromium. Proper shortcuts interpretation should be up to the client, not some workaround in the lower levels. For the sake of consistency, physical-to-logical key translations should be left to the lower levels alone — shortcuts should be interpreted strictly according to their keysyms (term for virtual/logical keycodes in XKB).

I discovered today that Chromium effectively disregards the state/level information of a key, rendering the XKB implementation of QSfNQL ineffective (as Ctrl+whatever results in Ctrl+the symbol associated with the unmodified state of the key). Internal processing disregarding the XKB keysym was implemented because there were apparently problems with the XLookupString string output of characters not supported by the set LC_CTYPE. So the developers decided to do away with XLookupString completely and perform internal keycode-to-character conversion by invoking XKB's KeyCodeToKeySym, and then using a lookup table for keysym-to-unicode. This disregards the modifier context so a different shortcuts layer is not captured.

I think they should just rely on XLookupString like Firefox. Locale is not really a problem as pretty much everyone uses utf8; plus if LC_CTYPE were improperly set, then all applications in the system would be affected upon input of some unsupported character, and it's not good to fix per-application at the expense of more problems. Also, if you insist on being completely locale-agnostic, you can still just take the keysym output from XLookupString and convert using the lookup table.

Issue was raised at Chromium 9 years ago.

TODO

• Create documentation on “known issues”
  • Section on problems that should be resolved in this repo: shortcomings in specific QSfNQLified layout implementations (i.e. resolvable, due to configuration flaws — such as #1 ); or broader limitations of the keysym / virtual key -level approach
  • Section on problems that should be resolved externally (i.e. issues for other programs, such as this Chromium problem), with philosophical principles justifying why
• (tentative) report to the Chromium project

What about non-Ctrl modifiers?

Hi Dongchen Yue, thank you for your research.
I'm the one who opened original issue:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/416

As not only Ctrl modifiers are commonly used for shortcuts, we need a solution that works for other modifiers, too (Ctrl, Alt, Meta(Super) at least, and their combinations. Shift is also frequently used as additional modifier for shortcuts).

I didn't look at your implementation but wondering if it allows to achieve the desired behavior easily.
Thanks.

Map to uppercase QWERTY for shortcuts containing “Shift”

Although my new EIGHT_LEVEL_ALPHABETIC_LEVEL_FIVE_LOCK_QSFNQL accommodates for 2 shortcut symbols layers, I thought that applications would be case-agnostic when handling Latin-letter shortcuts. Apparently it's not the case: The Gnome terminal shortcut for new tab, Ctrl+Shift+T only works for the uppercase keysym T, but not t.

Remedy: change lines like —
key <AC01> { [ u, U, backslash, NoSymbol, Home, Home, includedin, NoSymbol, a, a ] };
into the following way
key <AC01> { [ u, U, backslash, NoSymbol, Home, Home, includedin, NoSymbol, a, A ] };.

Does not work for Blender under Wayland

Have not tested with X11. But for Wayland at least, the shortcuts remain in their Neo positions.