-
Notifications
You must be signed in to change notification settings - Fork 795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Displaying images #163
Comments
Not that this is exactly what you are looking for, but, in https://github.com/knipferrc/fm I render the images as a string. Its not super high quality, but a little nicer than ASCII characters |
You may find this list of bitmap protocols and supporting terminal emulators of use: https://www.reddit.com/r/linux/comments/t3m7zm/quick_roundup_of_bitmap_graphics_availability_in/ |
For quick'n'dirty partial support two things might be enough to support Kitty graphics protocol (and sixel, too):
Sixel graphics is usually displayed correctly by bubbletea if not truncated (i.e. short images or properly newlined images) but kitty graphics is not displayed even when the APC code is not (apparently) mangled by the rendering engine. Kitty graphics is much more powerful but the rendering is also a bit more complex so this may actually be a problem with how |
Is there any updates/plans on this enhancement? @jficz @bashbunni @cwqt |
Hey @BominRahmani no plans at the moment to bring image support to Bubble Tea. It's just not adopted by enough terminal emulators right now for us to offer official support for it. Compatibility is super important to us |
Just to add some more context here, native terminal images (like sixel and so on) are functionally impossible to handle in TUIs because they can't be redrawn in the same way text can. That said, a half-block implementation would work (like the way @mistakenelf did it) and I could see us adding support for that in Lip Gloss at some point. |
Native terminal images can and have been done inside TUIs smoothly, though not supportable on every terminal. The TUI side is indeed much harder than the terminal side, but some good discussion and notes for doing images inside TUI were collected in the zellij issue for this. Zellij also did a really cool thing their sixel encoder/decoder, such that they did not need to solve the palette generation problem. (Unlike jexer where different image formats are converted internally to 32-bit ARGB and then re-encoded to whatever it detects the terminal can support.) On the terminal side, there are quite a few now supporting sixel, either in mainline or with a patch: https://www.arewesixelyet.com/ ; and also more are supporting iTerm2 and kitty protocols. Whether you choose to implement or not, hope you always have fun coding. 😀 💗 |
Hey I want to use kittys terminal graphics protocol in my project to display twitch emotes. I made a small proof of concept using unicode placeholders, sadly it does not work with the WithAltScreen settings enabled, but it works without. Any hints/tips how I can hack image support into bubbletea for my use case? 😀 |
ratatui-image would be another good reference (supports redrawing and resizing). |
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
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
Windows Terminal (preview) now supports sixel since 1.22. |
Would be cool to be able to display images in the CLI (think displaying graphs with a higher resolution than ASCII characters) - this kind of thing has been implemented in projects like neofetch using various image backends (see https://sw.kovidgoyal.net/kitty/kittens/icat/ for example)
The text was updated successfully, but these errors were encountered: