Skip to content
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

Open
cwqt opened this issue Nov 29, 2021 · 11 comments
Open

Displaying images #163

cwqt opened this issue Nov 29, 2021 · 11 comments
Labels
enhancement New feature or request

Comments

@cwqt
Copy link

cwqt commented Nov 29, 2021

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)

image

@mistakenelf
Copy link

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

@bashbunni bashbunni added the enhancement New feature or request label Apr 23, 2022
@AutumnMeowMeow
Copy link

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/

@jficz
Copy link

jficz commented May 22, 2023

For quick'n'dirty partial support two things might be enough to support Kitty graphics protocol (and sixel, too):

  1. detect image APCs here and don't truncate lines containing them (and also make sure it is rendered fully if it is a multiline APC (sixel) - that doesn't always work (probably) because of the terminal height detection but I didn't do any in-depth debugging there yet.
  2. make sure they're rendered properly (not sure how to do that with Kitty graphics)

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 termenv is used but this is just a speculation on my side at this point.

@BominRahmani
Copy link

Is there any updates/plans on this enhancement? @jficz @bashbunni @cwqt

@bashbunni
Copy link
Member

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

@meowgorithm
Copy link
Member

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.

@AutumnMeowMeow
Copy link

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.

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. 😀

💗

@meowgorithm
Copy link
Member

I stand corrected. In that, I wouldn't mind seeing experimental support for images — though it's not a priority for us internally at the moment. That said, PRs on Lip Gloss as a starting place are welcome — I'd use viuer as a general reference.

@julez-dev
Copy link

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.

without alt screen

with alt screen

Any hints/tips how I can hack image support into bubbletea for my use case? 😀

@aschey
Copy link
Contributor

aschey commented Aug 10, 2024

ratatui-image would be another good reference (supports redrawing and resizing).

aymanbagabas added a commit that referenced this issue Aug 12, 2024
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
aymanbagabas added a commit that referenced this issue Aug 12, 2024
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
aymanbagabas added a commit that referenced this issue Aug 12, 2024
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
aymanbagabas added a commit that referenced this issue Aug 19, 2024
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
@codr1
Copy link

codr1 commented Sep 19, 2024

Windows Terminal (preview) now supports sixel since 1.22.
So all WSL users are now on the table.
Between iterm and Windows terminal I would say that a good majority of the users now have graphics support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

10 participants