mirror of
https://github.com/ghostty-org/ghostty.git
synced 2025-12-31 02:32:13 +00:00
534aa508d6
Compromise solution to #7356 XKB is naughty. It's really really naughty. I don't understand why we didn't just kill XKB with hammers during the Wayland migration and change it for something much better. I don't understand why we're content with what amounts to an OS-level software key remapper that completely jumbles information about original physical key codes in order to fake keyboard layouts, and not just let users who really want to remap keys use some sort of evdev or udev-based mapper program. In a sane system like macOS, the "c" key is always the "c" key, but it's understood to produce the Unicode character "ц" when using a Russian layout. XKB defies sanity, and just pretends that your "c" key is actually a "ц" key instead, and so when you ask for the keybind "Ctrl+C" it just shrugs in apathy (#7309). And so, we took matters into our own hands and interpreted hardware keycodes ourselves. But then, a *lot* of people have the ingrained muscle memory of swapping Escape with Caps Lock so that it is easier to hit. We respect that. In a sane system, they would use a remapper that actually makes the system think you've hit the Escape key when in reality you've hit the Caps Lock key, so in all intents and purposes to the OS and any app developer, these two just have their wires swapped. But not on Linux. Somehow this and the aforementioned case should be treated by the same key transform algorithm, which is completely diabolical. As a result, we have to settle for a compromise that truly satisfies neither party — by allowing XKB remaps for keys that don't really change depending on the layout. The Linux input stack besets all hopes and aspirations.