Kitty Keyboard Protocol #869
Comments
|
Hi! So if you're targeting all terminals you simply cannot detect release events as terminal input handing is rather archaic. Adding support for the Kitty keyboard protocol would add support for release events and a bunch of other nice things, but bear in mind that there are only a few terminals that support the protocol at the moment. Maintainer's notes:fixterms/ A large, high fidelity range of input options, including key release, are available in Windows as evidenced in #140. We didn't merge that because of the large amount of Windows-only code and the maintenance burden that would come with it. |
|
Just a note that this is currently in development on the |
|
Hey @meowgorithm, wondering if there is any update on this? I notice that the branch went untouched very quickly (March 1st). Has the work moved elsewhere or is there a plan for future implementation of the Kitty keyboard protocol? Thanks |
|
Same, I'm also waiting for this to be implemented. I'd like to take the issue up if no one is working on it |
Currently, Bubble Tea uses a simple lookup table to detect input events. Here, we're introducing an actual input sequence parser instead of simply using a lookup table. This will allow Bubble Tea programs to read all sorts of input events such Kitty keyboard, background color, mode report, and all sorts of ANSI sequence input events. Supersedes: #1014 Related: #869 Related: #163 Related: #918 Related: #850 Related: #207
Currently, Bubble Tea uses a simple lookup table to detect input events. Here, we're introducing an actual input sequence parser instead of simply using a lookup table. This will allow Bubble Tea programs to read all sorts of input events such Kitty keyboard, background color, mode report, and all sorts of ANSI sequence input events. Supersedes: #1079 Supersedes: #1014 Related: #869 Related: #163 Related: #918 Related: #850 Related: #207
Currently, Bubble Tea uses a simple lookup table to detect input events. Here, we're introducing an actual input sequence parser instead of simply using a lookup table. This will allow Bubble Tea programs to read all sorts of input events such Kitty keyboard, background color, mode report, and all sorts of ANSI sequence input events. Supersedes: #1079 Supersedes: #1014 Related: #869 Related: #163 Related: #918 Related: #850 Related: #207
|
Hi all! This is indeed in active development; we’ve moved the feature through a few branches. We were planning on including it as part of a larger update but we may break it out to get it implemented sooner. We’ll keep this issue updated with progress. |
Currently, Bubble Tea uses a simple lookup table to detect input events. Here, we're introducing an actual input sequence parser instead of simply using a lookup table. This will allow Bubble Tea programs to read all sorts of input events such Kitty keyboard, background color, mode report, and all sorts of ANSI sequence input events. This PR includes the following changes: - Support clipboard OSC52 read messages (`OSC 52 ?`) - Support terminal foreground/background/cursor color report messages (OSC10, OSC11, OSC12) - Support terminal focus events (mode 1004) - Deprecate the old `KeyMsg` API in favor of `KeyPressMsg` and `KeyReleaseMsg` - `KeyType` const values are different now. Programs that use int value comparison **will** break. E.g. `key.Type == 13` where `13` is the control code for `CR` that corresponds to the <kbd>enter</kbd> key. (BREAKING CHANGE!) - Bubble Tea will send two messages for key presses, the first of type `KeyMsg` and the second of type `KeyPressMsg`. This is to keep backwards compatibility and _not_ break the API - `tea.Key` contains breaking changes (BREAKING CHANGE!) - Deprecate `MouseMsg` in favor of `MouseClickMsg`, `MouseReleaseMsg`, `MouseWheelMsg`, and `MouseMotionMsg` - Bubble Tea will send two messages for mouse clicks, releases, wheel, and motion. The first message will be a `MouseMsg` type. And the second will have the new corresponding type. This is to keep backwards compatibility and _not_ break the API - `tea.Mouse` contains breaking changes (BREAKING CHANGE!) - Support reading Kitty keyboard reports (reading the results of sending `CSI ? u` to the terminal) - Support reading Kitty keyboard and fixterms keys `CSI u` - Support reading terminal mode reports (DECRPM) - Bracketed-paste messages now have their own message type `PasteMsg`. Use `PasteStartMsg` and `PasteEndMsg` to listen to the start/end of the paste message. - Bubble Tea will send two messages for bracketed-paste, the first is of type `KeyMsg` and the second is of type `PasteMsg`. This is to keep backwards compatibility and _not_ break the API - Support more obscure key input sequences found in URxvt and others - Support reading termcap/terminfo capabilities through `XTGETTCAP`. These capabilities will get reported as `TermcapMsg` - Support reading terminfo databases for key input sequences (disabled for now) - Support reading [Win32 Input Mode keys](https://github.com/microsoft/terminal/blob/main/doc/specs/%234999%20-%20Improved%20keyboard%20handling%20in%20Conpty.md#win32-input-mode-sequences) - Support reading Xterm `modifyOtherKeys` keys TODO: - [x] Parse multi-rune graphemes as one `KeyPressMsg` storing it in `key.Runes` - [x] Kitty keyboard startup settings and options #1083 - [x] Xterm modify other keys startup settings and options #1084 - [x] Focus events startup settings and options #1081 - [x] Fg/bg/cursor terminal color startup settings and options #1085 Supersedes: #1079 Supersedes: #1014 Related: #869 Related: #163 Related: #918 Related: #850 Related: #207
Is your feature request related to a problem? Please describe.
It would be nice to see a solution to detecting key release events. Currently, for any action that requires this functionality in my Bubbletea apps I have replaced it with pressing the key to toggle which is less than ideal.
Describe the solution you'd like
The ideal solution would be to have an
actionType(or similar) field that determines what happened (press, release, etc). Unfortunately, this would likely break a lot of existing code, so another solution would be to add release versions of all the basic keys.Describe alternatives you've considered
I've considered cloning the Bubbletea package for projects that require it, and adding the functionality using solutions such as gohook. I am unsure of other potential solutions.
Additional context
If anyone has other ideas of how this could be achieved, either on my own or how I could implement this better into the Bubbletea package, please let me know!
The text was updated successfully, but these errors were encountered: