Canop
Request: Support the kitty image protocol's "unicode placeholders" method
Kitty relatively recently added this unicode placeholders aspect to their image protocol. If broot makes use of it (and assuming the user's terminal emulator supports it as well) that would add kitty image protocol support for tmux users, whereas tmux users currently don't have that when using broot.
There is a rust implementation for reference in the yazi codebase.
Unfortunately, as of this posting, the only terminal emulators to support this part of the protocol (I think) are Kitty itself, and Ghostty.
It's being tracked as an issue for Wezterm here, where a fork is linked with support added.
Related:
- #568 (sixel implementation is an alternative path to tmux-compatible previews)
I haven't been able to preview images with broot in Ghostty, is this what's needed for that?
I haven't been able to preview images with broot in Ghostty, is this what's needed for that?
I think that should already work, except in the case that you're using tmux as well.
Broot will need to support either sixel or the Unicode placeholder thing for tmux users to get good previews, and ghostty may never add sixel support.
I haven't been able to preview images with broot in Ghostty, is this what's needed for that?
What OS are you using?
On Linux/macos there is an ioctl/TIOCGWINSZ function call that returns the size of the console window which is not supported on Windows. This is what broot uses on unix platforms when rendering images with the Kitty protocol, and there is a cfg directive to fallback to primitive console rendering when the OS=Windows, leading to something very blocky/blurry.
I have implemented the equivalent functionality using Windows API calls (via official windows crate) thinking it was a drop-in replacement, but something else in the rendering pipeline must need changing because it just draws a black area.
I know very little about the Kitty protocol or Rust so didn't go any further.
@dkmar Can you tell us more about your OS & broot version ? Can you please post the debug log (eg do BROOT_LOG=debug br then open in preview the image and quit broot, then post the broot.log file).
Wow fast replies 😅. I'm on macOS Sequoia 15.2, broot 1.44.6. Image previews aren't working in Ghostty, but they do work in Kitty. Here is my log + video for Ghostty, and my log for kitty.
https://github.com/user-attachments/assets/c74234f6-dc4a-49ce-a7dd-677406b8b11e
@dkmar I don't see any problem in the log. Please try with this at the start of your broot config:
kitty_graphics_transmission: chunks
@dkmar I don't see any problem in the log. Please try with this at the start of your broot config:
kitty_graphics_transmission: chunks
That fixes it! Thank you
Please try with this at the start of your broot config:
kitty_graphics_transmission: chunks
This works when using Ghostty - the one issue is this is relatively slow, as the manual says: dystroy.org/broot/conf_file/
Two transmission media are possible: chunks: slow but works remotely temp_file: faster but doesn't work when broot is remotely executed, default
If the temp_file method would be significantly faster, wonder what it would take for this method to work w/ Ghostty.
If the
temp_filemethod would be significantly faster, wonder what it would take for this method to work w/ Ghostty.
I don't speak rust, so I can't follow the code very well, but it looks to me like Broot is using the temporary file transmission medium (i.e. t=t), but possibly not using a valid path (the protocol has certain requirements that need to be met for a path to be considered temporary).
Some terminals will still display images from an invalid path, but just won't delete the file afterwards (so you're going to have a bunch of temporary files left on the system if you're not deleting them yourself). However, some terminals won't display the image at all, and I suspect that's the case for Ghostty.
Assuming my theory is correct, you can either fix the issue by making sure you're using a valid temporary file path, or you can change the transmission medium to the simple file type (i.e. t=f), and then also make sure you cleanup the file yourself.
the protocol has certain requirements that need to be met for a path to be considered temporary
Reminds me of https://github.com/ghostty-org/ghostty/discussions/5536#discussioncomment-12035017, https://github.com/ghostty-org/ghostty/pull/4451 and https://github.com/ghostty-org/ghostty/discussions/5774, which look like they are relevant.
Same here: Preview images do not show up in Ghostty, unless kitty_graphics_transmission: chunks is set.
Ghostty v1.1.2 broot v1.45.0
If the
temp_filemethod would be significantly faster, wonder what it would take for this method to work w/ Ghostty.
temp_file works for me with ghostty, with changes from this PR: https://github.com/Canop/broot/pull/1034 It's definitely faster than chunks but larger images still make navigation laggy since broot waits for each image to render before taking input ? (not sure about that)
temp_file works for me with ghostty, with changes from this PR: #1034
Interesting but I couldn't get it to work with Ghostty tip (1.2+) on Mac, even after setting export TMPDIR=/tmp in Ghostty zsh. Maybe it only works on Linux. This tmp setting is not a valid Ghostty setting so I assume the PR is referring to setting this as an env var. Still have to use chunks which is slow but works. Also I mainly use yazi now which is also not super fast with image preview but works ok.
@edrozenberg You tested with the new main after merge of #1034, right ?
Ah no I was using release broot 1.49.1, will have to try with the merge. Thanks!
Please give some feedback. We're currently in a test period before releasing the current main.
Tested with ghostty 1.1.3 and tmux, with kitty_graphics_display: unicode added to broot config, on Plasma X11, and it worked great!
Tested with wezterm the same way, which doesn't yet support kitty's unicode placeholders method, and it did show the images but not in the right place, and not until changing the selected entry once. That was actually much more functional than I expected.