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

[John Ralls <jralls ceridwen us>]

> On Oct 17, 2017, at 3:37 AM, Jiří Techet <techet gmail com> wrote:
>
> Hi John,
>
> I have some more observations and questions.
>
> <icon-theme icons="all"> doesn't seem to work at all with the Papirus theme - I just get empty theme 
> directories with that inside the bundle. Using <data> for copying the icons inside the bundle works 
> partially but symlinked directories such as 16x16@2x -> 16x16 are missing completely inside the bundle and 
> icons are too small because of that on retina displays.
>
> Is there any difference between <icon-theme icons="all"> and <data>? I understand that <icon-theme> behaves 
> differently when the "icons" parameter has a different value but in the case of "all" I assume one can 
> replace <icon-theme> with <data> without any functionality loss - am I right?
>
> If so I think that it would be more universal solution to extend the <data> tag with some "copy_symlinks" 
> parameter defaulting to "false" rather than modifying the <icon-theme> tag.
>
> Finally, is it OK if I prepare a patch for such a feature? I want to avoid the situation when I spend time 
> looking at the code and at the end it's not merged because you are completely against the feature.

Jiri,

That’s because the icons-theme copy-icons function deliberately skips svgs. There’s even a comment “they are 
really big and not really used”. That was written in the days of Gtk2 and is I suppose obsolete now.

Yes, there are differences between <icon-theme> and <data>.: <data> grabs everything in a directory that 
matches a wildcard spec and is optionally recursive. <icon-theme> gets the index.theme and a selection of the 
*.png files in the various subdirectories depending on the value of the icons attribute; the choices are 
“all” (the default), “none”, and “auto”; the latter gets only the ones named in the binaries; I don’t know 
that that works with Gtk3’s named icons.

I started on adding symlink-handling to the copy function and I have the trivial case  where the link is a 
relative path and the target will get copied sooner-or-later to the same relative location, but that’s too 
easily broken by absolute links, relocated relative targets, or targets that aren’t copied.

I don’t agree that the icon-theme tag should be abandoned in favor of the data tag, though I’ve decided that 
better symlink handling throughout is necessary; for example your original problem with libvte could have 
been avoided if libvte.dylib had been recognized as a symlink and linked correctly in the bundle.

Regards,
John Ralls