An icon the desktop can actually draw - #50
Merged
Merged
Conversation
Reported from the desktop: the application icon does not render. The file was installed where it belongs,
the desktop entry validated, and GTK's icon theme resolved the name to the file — `has_icon` said true.
It had never drawn it. `has_icon` consults an index; it does not load anything.
gdk-pixbuf recognises a file by sniffing its first bytes, and its SVG loader looks for `<svg` near the
start. This icon opened with a nine-line comment explaining the drawing, which put `<svg` 501 bytes in:
a working system icon <svg at byte 55 loads
ours <svg at byte 501 "couldn't recognize the image file format"
ours, comment removed <svg at byte 40 loads
The file was valid SVG the whole time, and nothing warns about this. The comment that broke it ended with
the words "nothing in the packaging depends on what is in here".
So the comment moved inside the element, where it says the same things and also says this. And CI now
draws the icon on every push, through gdk-pixbuf, because that is the only thing that sees the bug:
`rsvg-convert` parses the file directly and accepts the broken one, and `gdk-pixbuf-thumbnailer` warns
about it and still exits 0. The check looks at whether a PNG came out. Against the broken file none does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The next person to improve this icon will put a comment at the top of it, because that is where comments go. Said beside the other things about the window that are not obvious from the code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The window fix and the icon fix touched the same three files and neither is about the other: the version becomes 0.5.15, and the README keeps what each of them had to say. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Shipping as v0.5.15. Reported from the desktop: the application icon does not render in Ubuntu.
Everything looked right
The file was installed where it belongs,
desktop-file-validatepassed, all three names agreed, and GTK's icon theme resolved the name to the file:has_iconconsults an index. It never draws anything. Asking the loader to actually draw it:The cause
gdk-pixbuf recognises a file by sniffing its first bytes, and its SVG loader looks for
<svgnear the start. This icon opened with a nine-line comment explaining the drawing, which put<svg501 bytes in:<svgat byteThe file was valid SVG the whole time — it parses, and
rsvg-convertrenders it happily. Nothing warns about this. The comment that broke it ended with the words "nothing in the packaging depends on what is in here".The fix
The comment moved inside the element, where it says the same things and now also says this.
The check
CI draws the icon on every push, through gdk-pixbuf, because that is the only thing that sees the bug:
rsvg-convertparses the file directly, accepts the broken one and exits 0 — a check built on it proves nothing.gdk-pixbuf-thumbnailerwarns about the broken file and still exits 0 — so the check looks at whether a PNG came out, not at the exit status.Against the broken file, none does: no output file at all. Against the fixed one, 1,865 bytes of PNG. Both were run on a real Ubuntu desktop before this check was written.
🤖 Generated with Claude Code