> 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.