https://bugs.kde.org/show_bug.cgi?id=435975
--- Comment #6 from [email protected] --- Here is some thoughts on fixterms/kitty approach vs another alternative, win32 input mode. I tend to believe that the win32 input mode is, in fact, much better designed. Arguments in its favor: 1. It's based on a time-tested keyboard event structure of Windows - there have never been complaints from application developers that something is missing in it. The structure is stable and hasn't changed for decades. 2. It avoids the overcomplication of kitty's mode-state stack. 3. It doesn't include unnecessary and hard-to-obtain field unshifted key. (I understand how to implement this on top of GTK - it would require an additional xkbcommon context that tracks the current kb layout - but that's an absurd amount of terminal-side complexity for something that can be handled in a single line on the application side, simply by normalizing case before hotkey checks.) 4. It clearly separates Unicode character (which depends on layout and modifiers) and key code (which does not), unlike kitty, which allocates four (!) separate fields for the same two concepts: key code, shifted key code, base layout key code, and Unicode text. 5. Accordingly, there is no pointless duplication of the same Unicode character between the shifted field and the Unicode text fiels (as happens in kitty). Moreover, in kitty, for roughly half of all keys, the key code field itself duplicates the same character code as those two fields. 6. Parsing is simpler - no nested delimiters. Because of its simplicity, it's trivial to integrate into applications. 7. It's supported out of the box on every Windows machine. 8. The specification is clear and unambiguous. 9. It doesn't carry the 50-year-old technical debt that kitty indirectly inherits. 10. It's already used outside the Windows ecosystem - for example, in magiblot's Turbo Vision fork and his turbo editor, and also in far2l - Linux port of classical file manager from the Windows world. On macOS, virtual key codes can be mapped the same way as in Wine, providing a familiar behavior at least for some users. Essentially, with kitty we get a beautifully formatted specification that is, in at least one case, impossible to fully adhere to - one that contains fundamental design flaws and is excessively overengineered. To be honest, its appeal was greatly overestimated due to the lack of competition. >From an engineering standpoint, a protocol based on win32 input looks like a far more attractive alternative. And it is already implemented for Konsole: https://invent.kde.org/utilities/konsole/-/merge_requests/1133 -- You are receiving this mail because: You are watching all bug changes.
