GNOME Bugzilla – Bug 730450
Support non-svg symbolic icons
Last modified: 2014-08-03 00:47:04 UTC
It would be nice to have a version of symbolic icons that don't use svg, so that we don't have a core dependency on librsvg which is less that fantastically maintained (and pretty slow).
Created attachment 276868 [details] [review] Add gtk-encode-symbolic-svg This utility loads a symbolic svg at a specified size and renders a png file in a special format that can be recolored later.
Created attachment 276869 [details] [review] icon-theme: Support recolorable .symbolic.png files If an icon theme has a file called "foo-symbolic.symbolic.png" which was converted from svg using gtk-encode-symbolic-svg we will read it in an recolor, allowing symbolic icons without using librsvg.
Created attachment 276870 [details] Example converted png
So it's essentially a bitmap with a 4 color colormap where each of the colors has 256 shades? That means no other colors may be present in the image? I don't mind a solution like this, but I'm not a huge fan of it. As far as I can see it doesn't solve a real problem. And it invents a whole new file format for it.
Well, somewhat like that. Each pixel has a 8bit alpha, and is a mix of 4 possible colors with the mix proportions being 256 shades. This is enough to encode all existing gnome symbolic icons, which means we could ship a symbolic icon theme that doesn't depend on librsvg (and which probably will be a lot faster at loading such icons). So, it does in fact solve a real problem, although I agree that its a pretty limited problem. We could create a more generic solution that allows any N colors + hardcoded colors, but that would require a completely custom file format, rather than just reinterpreting an existing one like png. Or, one could i guess add extra colors by just making the image larger. I.e. for a 48x48 icon it could be made 48x96, with the upper copy having hardcoded colors and the lower one the recolorable parts. That will make such icons even more weird when they leak into non-supporting apps though.
if you want to go into gdk-pixbuf, you could actually use the png spec and add a separate chunk - then the icons could work like normal pngs in unsuspecting software.
Thats another level of custom image format though... You may need to modify libpng to parse it correctly, at least if the extra chunk is complex like compression and other details used for the normal pixels.
One option may be to use tiff. That supports layer, but unfortunately it also supports about a gazillion other features...
From my point of view SVG is a hard dependency of GTK anyway. Because there's still gonna be scalable icons in the theme... And I don't loading times of SVGs was ever an issue either. Even back when all Adwaita assets were still SVGs and they were all loaded on startup, nobody complained. So I think as long as we get the caching layer in the icontheme right, there shouldn't be any issues...
Benjamin: The main problem is that librsvg and libcroco are basically unmaintained, and that relying on svg in themes to work basically makes them a hard dependency of gtk+. This is not an ideal situation.
(In reply to comment #4) > So it's essentially a bitmap with a 4 color colormap where each of the colors > has 256 shades? That means no other colors may be present in the image? This is how symbolics have always worked. Four colors: fg, warning, error, success. PNG files also allow for multiple IHDR chunks, so we could have four A8 planes, and add more when we want additional colors. I think relying on RGBA channel data for now is probably fine, though.
Jasper: That is not *quite* true. symbolic svgs *can* use absolute colors, but yeah, thats generally how it works in practice.
I'd say that any symbolic icon SVG that has an absolute color is violating the spirit of symbolics, even if not the letter :)
Created attachment 282152 [details] [review] Add gtk-encode-symbolic-svg This utility loads a symbolic svg at a specified size and renders a png file in a special format that can be recolored later.
Created attachment 282153 [details] [review] icon-theme: Support recolorable .symbolic.png files If an icon theme has a file called "foo-symbolic.symbolic.png" which was converted from svg using gtk-encode-symbolic-svg we will read it in an recolor, allowing symbolic icons without using librsvg.
Created attachment 282154 [details] [review] Support pre-rendered symbolic pngs This uses the new gtk-encode-symbolic-svg feature of Gtk to pre-render svgs as recolorable pngs. The pngs are loaded faster and can be used without librsvg which avoids librsvg as the required dependencies for Gtk+.
Created attachment 282236 [details] [review] Add gtk-encode-symbolic-svg This utility loads a symbolic svg at a specified size and renders a png file in a special format that can be recolored later.
Created attachment 282237 [details] [review] icon-theme: Support recolorable .symbolic.png files If an icon theme has a file called "foo-symbolic.symbolic.png" which was converted from svg using gtk-encode-symbolic-svg we will read it in an recolor, allowing symbolic icons without using librsvg.
Attachment 282236 [details] pushed as 50ba3c7 - Add gtk-encode-symbolic-svg Attachment 282237 [details] pushed as 1d68801 - icon-theme: Support recolorable .symbolic.png files
Attachment 282154 [details] pushed as 05492d1 - Support pre-rendered symbolic pngs