https://bugs.kde.org/show_bug.cgi?id=478219
--- Comment #15 from Wismill <[email protected]> --- (In reply to Nate Graham from comment #14) > That sounds interesting. Could "key <XXXX>" be a keyboard shortcut using > modifier keys? Not exactly: the `key <XXXX> { … }` statement declares a lookup table (level → keysyms + actions) for a *single* keycode. It then requires another lookup table, a key type, which maps modifier *states* to levels. E.g. for an alphanum key of a Latin script, the mapping is typically: - no active modifier → level 1 - shift → level 2 - caps → level 2 - shift + caps → level 1 - (scripts requiring AltGr have more entries, on the same model) As you can see, it does not map directly key combos, but rather modifier combos. There are 2 limits to this approach: 1. If one changes the type of a key in order to add the shortcuts, it has to be done carefully so that every combination of modifiers works as intended on the key. 2. Apps struggle to respect some XKB concepts, most notably the *consumed modifiers*. E.g. If you map "Test !" to Meta+Ctrl+Alt+T as proposed by the OP, then apps should not interpret the modifiers Meta+Ctrl+Alt, because they have been “consumed” to produce the text output. Let me provide you a somehow similar use case I am trying to solve: some people are used to “Ctrl+Alt” (2 keys) on Windows instead of AltGr, which produces the same modifiers but with only 1 key. They naturally want to use the same on Linux, but it remains difficult because all my current attempts failed due to apps interpreting Control or Alt although they are consumed (e.g. Konsole does it). Because of the incorrect implementation *in the apps*, what can be achieved with XKB is unfortunately limited. I have some ideas to mitigate this, but I am quite alone working on libxkbcommon, so it takes time. The keymap API seems an important milestone to me, the next one being mitigating the poor use of XKB in apps. -- You are receiving this mail because: You are watching all bug changes.
