GitXplorerGitXplorer
y

QSfNQL

public
0 stars
0 forks
4 issues

Commits

List of commits on branch main.
Verified
923fa1d4937d37bd6fb3f7619e76f824bb2e16bb

Update evdev.xml

yyue-dongchen committed a year ago
Unverified
4df4abf79fd3de4d85dca9440598afef993ba7cf

[Add QSfNQLified layout] [XKB] neo

yyue-dongchen committed a year ago
Unverified
25dfe46ebddd07b3f62c234bf8ae8843e5c673c9

Create README.md

yyue-dongchen committed a year ago
Unverified
08197f42d876ebe89e28d96ce8a36c4d047b66a0

Initial commit

yyue-dongchen committed a year ago

README

The README file for this repository.

QSfNQL

QWERTY Shortcuts for Non-QWERTY Layouts

What this is

We spend a lot of time using keyboards to interact with computers. Following people's needs to input languages containing symbols that are not present or easily accessible on the US ANSI keyboard, desktop operating system developers have developed software to map keyboard scancodes to characters flexibly, defined by configuration files.

This is a double-edged sword. Applications (by and large) act on shortcuts based on whatever symbols are sent to them by the lower levels of the keyboard input stack. Since the base layer[glossary] for many layouts is not QWERTY, shortcuts are not necessarily triggered according to their ANSI QWERTY positions. An example problem scenario would be someone confusing Ctrl+A with Ctrl+Q as they switch back-and-forth between a French AZERTY layout, and an Arabic layout that falls back to QWERTY for Ctrl shortcuts: Whilst the Arabic layout is active, they use their AZERTY-oriented muscle memory to perform Ctrl+A, which results in Ctrl+Q and the application unexpectedly quits. Replace that French AZERTY layout with something less QWERTY-like such as DVORAK, Colemak or Neo — and muscle memory conflicts become even more disruptive.

Thus, even ignoring QWERTY-oriented shortcuts ergonomics, it is highly necessary for anyone who frequently switches between several layouts to have shortcuts fixed in uniform positions. This project aims to be a repository for configurations of non-QWERTY layouts, adapted to use QWERTY as their Ctrl layer.

Implementation

To implement such layouts, it is necessary to understand, in the context of an operating system's keyboard input stack, the components responsible for translating absolute key positions into key symbols. Below is an overview of the respective approaches on a few systems.

Linux (Wayland and X11 display servers)

Keyboard input stack in X11 systems, depicting (from bottom to top of image) the kernel, X Server, and three clients — display manager, window manager, and web browser — each sitting on top of a GUI toolkit and Xlib

Keyboard input stack in X11 systems
Linux Professional Institue Inc | Creative Commons BY-NC-ND 4.0

Both X11 and Wayland use XKB[glossary]-style configuration files to set the keymaps. With X11, XKB is integrated into the display server, sending processed key events to their clients. In the case of Wayland, XKB has been extracted into the library libxkbcommon, which the clients themselve invoke when they demand a translation of the keycodes sent via libinput.

So on Linux systems, the configurations manifest in XKB-style configuration files. X11 uses /usr/share/X11/XKB/; any modification requires root. libxkbcommon on Wayland additionally scans $HOME/.config/XKB/, and allows for user-specific modifications.

macOS

Haven't looked much into it. But by the looks of it the configuration XML of .keylayout files seem pretty well defined; and there's even a polished open-source GUI program, “Ukelele”, that allows layout definition graphically.

Windows

No clue. Contributions would be greatly appreciated. I've heard that the Microsoft Keyboard Layout Creator does not work on Windows 11.

Glossary

  • base layer: the symbols produced when no modifier key (`Shift`, `AltGr`, `CapsLock`, etc.) is active

  • XKB: "X Keyboard Extension", a part of X11 display servers supporting complex keyboard layouts