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

[Jiří Techet <techet gmail com>]

Hi John,

On Tue, Oct 17, 2017 at 4:24 PM, John Ralls <jralls ceridwen us> wrote:

> 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 think the code making the copy doesn't really have to make all those complicated checks whether something is a relative or absolute symlink and where exactly it leads. I'd say that when <icon-theme copy_symlinks="true"> is specified, it will copy all the symlinks, no matter where they point. This option could be documented as "it's the responsibility of the user to use this parameter only when the symlinks are relative and don't point outside the resulting bundle". Should work just fine for themes.

 

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.

Yes, if there was a symlink instead of the copied file, it would have fixed the problem. I had a simpler implementation in mind as I mentioned above where no additional checks of the symlinks are done but of course if you want to add a full blown "automatically copy all symlinks that don't point outside the bundle", it would be great of course.

Jiri