https://bugs.kde.org/show_bug.cgi?id=435975
Kovid Goyal <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from Kovid Goyal <[email protected]> --- (In reply to Ivan Sorokin from comment #6) > 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. I happened to chance across this and boy it is so full of wrong headed and barely coherent assertions, I dont even know where to start. > > 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. You want a cross platform protocol to adopt a single OS specification, seriously?!! And you tout that as an advantage!! > > 2. It avoids the overcomplication of kitty's mode-state stack. The so called "overcomplication" means, for instance, that at lower enhancement levels, a crash or an ssh disconnect does not leave the terminal in an unusable state where the user cannot even type reset. A basic QoL feature that win32-input-mode lacks. It further means that applications that dont need release events dont have to deal with them. This has the huge advantage that, for example, an application can quit on a keypress not a key release and not worry about the terminal sending the release event after the application has quit leaving garbage to be printed on the tty. > > 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.) It's only hard for you, the dozen or so terminal implementations of this protocol disagree with you. And the fact that you think changing between shifted and unshifted keys is a matter of case change shows you have zero understanding of how keyboards work. Please explain to me how a case change will normalize between plus and equal which, in the most widely used keyboard layout in the world, by far, the US PC keyboard layout are distinguished by shift. Indeed, if you spent a bit more time studying how keyboard key mapping worked you would realize that shift can be used to perform arbitrary, layout dependant mapping between unicode codepoints. > > 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. > Again you dont know what you are talking about. There is no such thing as a "key code". Different hardware keyboards produce different electrical signals these get turned into arbitrary numbers by the OS kernel. These numbers vary from platform to platform. All cross platform keyboard protocols therefore never adopt the numbers from one platform. Instead they define an unambiguous "encoding" using numbers or names or symbols or as in the case on the kitty keyboard protocol unicode codepoints. You declare those "four!!" fields are the same thing. They are not. Every single field can differ in different situations and is needed for maximally robust shortcut matching. > 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. Again the duplication is only pointless to you, because again, you haven't a clue what you are talking about. > > 6. Parsing is simpler - no nested delimiters. Because of its simplicity, > it's trivial to integrate into applications. It takes approx 50 lines of code to parse the kitty keyboard protocol key structure. But I suppose that's too complex for you. Why am I not surprised. Proof, the decode_key_event() function in the kitty source code is exactly 37 lines long in Python. It will be about 100 lines in a less expressive language, proof KeyEventFromCSI is 97 lines long in Go in the kitty source code. > > 7. It's supported out of the box on every Windows machine. > And this matters to Konsole, because? > 8. The specification is clear and unambiguous. So is the specification of the kitty keyboard protocol > > 9. It doesn't carry the 50-year-old technical debt that kitty indirectly > inherits. What technical debt is that? > > 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. > You mean in two applications at least one of which, you wrote. In contrast lets see the roster of applications supporting the kitty protocol. vim, neovim, kakoune, emacs, dte, helix, flow, yazi, awrit, aerc, far2l and on and on. > On macOS, virtual key codes can be mapped the same way as in Wine, providing > a familiar behavior at least for some users. I have no clue what this means. You are suggesting konsole use wine code on macOS? > > 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. You forgot to add, in your, extremely flawed, opinion. > > From an engineering standpoint, a protocol based on win32 input looks like a > far more attractive alternative. To *you*. > > And it is already implemented for Konsole: > https://invent.kde.org/utilities/konsole/-/merge_requests/1133 I hope for their sake the Konsole maintainers dont merge code written by you. It will be full of bugs stemming from an appalling lack of understanding of even the basics of how keyboards work. -- You are receiving this mail because: You are watching all bug changes.
