[konsole] [Bug 435975] Implement fixterms

[bugzilla_noreply at kde.org]

https://bugs.kde.org/show_bug.cgi?id=435975

--- Comment #6 from unxed at mail.ru ---
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 the assignee for the bug.