Re: [gtk-osx-users] Preserving symlinks in bundle for themes

[John Ralls <jralls ceridwen us>]

> On Oct 14, 2017, at 4:50 PM, Jiří Techet <techet gmail com> wrote:
>
>
>
> On Sat, Oct 14, 2017 at 7:38 PM, John Ralls <jralls ceridwen us> wrote:
>
>
> > On Oct 14, 2017, at 2:58 AM, Jiří Techet <techet gmail com> wrote:
> >
> > Hi John,
> >
> > I've been playing with GTK3 version of Geany (GTK3 seems to be getting in a usable shape finally) and 
> > theming support. I used the Papirus icon theme, removed icons not needed for Geany and got to the size of 
> > about 6MB, which is acceptable. However, when creating bundle, all symlinks within the theme get replaced 
> > with copies of the files and the resulting size of the theme in bundle becomes about 50MB. This is by far 
> > the largest portion of the bundle.
> >
> > Is there some way to prevent this? It's clear that the bundler tries to avoid situations when symlinks 
> > lead to stuff outside the bundle but with icons, symlinks are always relative to the icon theme directory 
> > so having them in the bundle should be safe.
> >
> > I think there could be some option of the <icon-theme> tag in the bundle settings file so users who know 
> > that symlinks don't point outside the bundle can use it to keep the symlinks.
> >
> > What do you think?
>
> You mean now that the first release of Gtk4 is out? :-/
>
> Unfortunately on OS X took a long time to get usable. Hopefully GTK 4 will be better.

Gtk4 is going to be heavily dependent on OpenGL. Apple has its own GL API that's different, so I'm not sure 
that Gtk4 will work at all on Quartz unless someone with serious GL chops gets involved and writes a backend 
for it.

> I don’t have a philosophical objection to copying symlinks into the bundle, but what’s getting symlinked 
> and why? Why can’t you have a single copy of each file and call it by its name?
>
> Names in icon themes are standardized
>
> https://developer.gnome.org/icon-naming-spec/
>
> plus there are many names corresponding to various MIME types which can then be displayed using 
> g_content_type_get_icon() dynamically for each file type you get using g_content_type_guess(). Icon themes 
> use a single icon e.g. for several MIME types and these then symlink to a single physical image such as
>
> image-bmp.svg -> image-x-generic.svg
> image-gif.svg -> image-x-generic.svg
> image-jpeg.svg -> image-x-generic.svg
> image-png.svg -> image-x-generic.svg≈

> Try to get e.g. the Papirus icon theme I mentioned from
>
> https://github.com/PapirusDevelopmentTeam/papirus-icon-theme
>
> and check how symlinks are used. For instance, there's a directory 16x16 containing 16x16 SVG icons. Then 
> there's a 16x16@2x directory which contains icons with 2x resolution for HiDPI displays and this one is 
> just a symlink to the 16x16 directory. If you get the theme try to "cp -r" it to another location which 
> creates a file copy of every symlink and compare the sizes - the difference is huge.
>
> This is not specific to this particular icon theme - basically all the icon themes you find do this trick 
> to save space. So I think it would be useful to allow symlinks for icon themes to save some space in the 
> bundle.

Yes, there's a list of standard icon names those names provide guidance to themes about what they need to 
provide. Themes are of course free to provide other ones as well, but there's no reason for them to have 
files with non-standard names and then symlink them to the standard names. Nobody's going to use the 
non-standard names.

The 16x16@s directory is a symlink to the 16x16 directory (which is wrong, it should point to 32x32). It 
contains nothing on its own. The directory with quad-resolution icons for 16x16 is 32x32. 32x32 is as big as 
you'd want for an icon on a regular screen, so there's a 64x64 resolution directory for the HiDPI version.

There's two schools of thought about different size icons. One is that you draw the icons at high precision 
(open source folks will use Inkscape) and save them as SVGs and let the rendering software take care of the 
squashing. That's the approach used in the official Gnome themes. More finicky artists are unhappy with the 
results of letting the renderer do the squashing and want to tweak the SVG for each resolution. That's 
apparently the approach taken by the Papirus folks.

But back to bundling: You don't really want SVGs in your bundle at all, and if you're worried about size then 
you only want the icons you need, not all n000 x 12 that Papirus provides forgetting about all of the useless 
symlinks. I suggest that you write a script to grep through Geany, Gtk, and any other graphical dependencies 
you have and get a list of the icons you actually need, then renders those into pngs in each resolution and 
install them in $PREFIX/share/icons/Papirus, and then bundle those. You'll get better performance and you 
won't need to bundle librsvg.

Regards,
John Ralls