kitty kb protocol for GNOME VTE #9293
Replies: 6 comments 4 replies
-
|
@kovidgoyal, hi, following our discussion in the Konsole bug tracker, this time I tried to write an implementation that covers 100% of the specification. However, I don’t really understand what to use to test the different bitwise flag-setting modes or the flag stack: in the applications I have at hand, everything worked even without these functions. In general, I would greatly welcome any help with testing and am ready to fix bugs if any are found. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure what you are asking. If you want to test the behavior of the
various progressive enhancement modes, you can do so by using printf to
set the mode you want and then running kitten show-key -m unchanged
Compare the reported key events against kitty or the spec or both.
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's exactly what I did when something wasn't working somewhere. What I'm asking is, for example, experienced [neo]vim and emacs users to compile VTE with my patch and make sure that everything that works in kitty will also work in VTE. I just don't know these editors well enough to check. The same applies to other applications, for example, the fish shell. |
Beta Was this translation helpful? Give feedback.
-
|
If gnome and kitty are producing the same bytes for the same keypresses
in the show-key kitten then GNOME will work correctly in vim and emacs,
once vim and emacs turn on the kitty keyboar dprocolo for GNOME
terminal.
|
Beta Was this translation helpful? Give feedback.
-
|
It's a bit difficult to manually test all the keys with all the modifier combinations. I'm considering automated testing, but I've never had to emulate input events in *nix before, so it'll take some time to figure it out. |
Beta Was this translation helpful? Give feedback.
-
|
In general, you dont need to. The thing about key events is the vast
majority of users use a very small fraction of possible key combinations
so testing a few judiciously chosed key paths covers 99% of use cases.
If you are interested in doing more automated testing, read on.
The easiest way to do so is to create some api in gnome terminal to
inject keys. For instance, you can do so in kitty using
kitten @ send-key
via remote control.
Or alternately, make a simple PR to kitty that tests the code path from
xkb_glfw.c to encode_glfw-key_event() have it iterate over a large
subset of XKB keysyms + modifiers and output the encoded bytes to a file
and treat that as a golden file to test your implementation against.
…On Tue, Dec 16, 2025 at 05:17:43AM -0800, unxed wrote:
It's a bit difficult to manually test all the keys with all the modifiers combinations. I'm considering automated testing, but I've never had to emulate input events in *nix before, so it'll take some time to figure it out.
--
Reply to this email directly or view it on GitHub:
#9293 (reply in thread)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
Beta Was this translation helpful? Give feedback.
-
|
I ended up solving this in a similar spirit, but with a slightly different approach. Instead of injecting events or relying on a golden file, I extracted the actual key-encoding logic from both kitty and VTE, wrapped them in mocked environments, and ran large-scale differential tests over thousands of key combinations. This avoids GUI dependencies and timing issues while giving deterministic, high-coverage results. In the readme I explained the reasons for the decisions made in more detail. The solution might seem a little quirky to you, but it does a great job of identifying behavioral discrepancies between VTE and kitty. The similar approach may be used by other terminal developers to test their terminals as well. |
Beta Was this translation helpful? Give feedback.
-
|
On Wed, Dec 17, 2025 at 09:19:28AM -0800, unxed wrote:
Okay, my solution might seem a little quirky to you, but it does a great job of identifying behavioral discrepancies between VTE and kitty. The similar approach may be used by other terminal developers to test their terminals as well.
https://github.com/unxed/vte2kitty
Seems fine to me, though to be more easily useful by other projects, it would be good to
generate a golden file.
|
Beta Was this translation helpful? Give feedback.
-
That's great to hear!
Yes, you're right. I'm quite willing to do this as soon as a request comes from any of the terminal developers. Or maybe I'll do it myself sometime in my spare time. |
Beta Was this translation helpful? Give feedback.
-
Done that.
to generate |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
So far it covers only part of the specification. However, the remaining parts should not be difficult to implement. Even in its current form, the available functionality is already sufficient for full-fledged operation of far2l, for example.
Feedback is welcome! If there is no feature that your application needs, please let me know — along with a test scenario.
https://gitlab.gnome.org/GNOME/vte/-/merge_requests/14
Beta Was this translation helpful? Give feedback.
All reactions