Behaviour of graphics using kitty protocol differs from kitty implementation

[MatanZ]

What Operating System(s) are you seeing this problem on?

Linux X11

WezTerm version

20220605-223126-4776c8d9

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Dsiplaying two images using kitty protocol with id=0 and the same placement id deletes the first one, showing only the second.

kitty protocol documentation says that image placements must have a unique (id, placement id) pair. Thus displaying a second image with the same pair deletes the first. The actual implementation in kitty of this protocol differs by allowing multiple placements if the id of the image is 0.

I do not know if the behavior is intentional, but I find it beneficial. This allows program to display multiple images without needing to keep a database of used ids. Keeping such database is not practical in the frequent case of different programs displaying images on the same terminal (such as icat or equivalent).

Thus, I believe it is better to conform to kitty implementation, rather than documentation in this case.

To Reproduce

Run the command echo -en '\e_Ga=T,f=100;' ; base64 -w 0 < /usr/share/icons/oxygen/96x96/places/start-here-kde-fedora.png ; echo -e '\e\\' twice. Kitty and konsole show two images, wezterm shown one.

Configuration

no config

Expected Behavior

Two images showing

Logs

No response

Anything else?

[kovidgoyal]

The documentations states that placement id is ignored when id=0. Therefore there can be multiple images with id=0 regardless of placement id. I have clarified the docs to that effect. https://github.com/kovidgoyal/kitty/commit/b71d2e04ca190de3f223c929d26690d26c7adb7d

[wez]

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.