Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)

[John Ralls <jralls ceridwen us>]

On Apr 15, 2011, at 10:45 AM, Alexander Larsson wrote:

> On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote:
>> On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote:
>>> On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote:
>>> 
>>> 
>>>>> Of course, some files are inherently made to be external, read by 
>>>>> other
>>>>> applications. Such files are hard to relocate, like application
>>>>> icons,
>>>>> desktop files, icon themes, widget themes, plugins, custom mimetype
>>>>> descriptions, dbus service files. I don't really know what to do
>>>>> with these.
>>>> 
>>>> A library can discover its current path by calling dladdr() on *nix
>>>> and MacOS X, and GetModulePath() on Windows. The library then loads
>>>> resources relative to that path.
>>> 
>>> Yes, thats is doable on many OSes, but its still kinda ugly, as it
>>> implies that the relative paths to the files are kept, and thus implies
>>> that things are stored in typical unix style hierarchies, etc. It is
>>> much cleaner to just have a single file.
>>> 
>>> It doesn't solve the inherently hard things listed above though, because
>>> the problem for them is that *other* things than the library itself
>>> loads these files.
>> 
>> Usually the tool used to solve this problem though is a file system.
>> 
>> An appdir like structure is a good compromise between other things
>> needing to easily access the data and having all the stuff in one
>> location that can be easily copied and moved around.
>> 
>> Another option might be to simply tar (but not [bg]zip) up the library
>> and related files and change the dynamic linker to mmap the correct
>> subsection of the file instead of the whole thing.
> 
> An appdir doesn't solve the issue here. Its not that its hard to load
> the file from the relocated file that makes it problematic. Its the fact
> that the "other" app doesn't even know about the existance of the file.
> 
> For instance, let us take a desktop file as an example. Applications
> typically install their desktop files in /usr/share/applications. That
> way "other" applications like the panel, the open with dialog, etc will
> find it, because they all look in that directory. There are some env
> vars you can set globally to manually make other apps look in a some
> specific other directory, but this is quite limited and doesn't work for
> random relocation of apps.
> 
> The same thing happens for the other types of files i mentioned above.
> dbus looks only for service files in /usr/share/dbus-1/services, gtk
> looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc.
> So, anything that has a file of this type is "hard" to relocate.
> 
> Also, apps that consume such files are also hard to relocate. Take
> nautilus for instance, it looks for extensions
> in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does
> extensions know where to install extensions?

At some point some system-level facility has to provide a way of registering such locations. M$Win and MacOSX provide both well known places and a facility for programs to let the system and other apps know where things are if the user put something somewhere else. Linux does too, it just that it's a bit clumsy: Environment variables. The problem for Glib isn't creating such a thing for Gnome (assuming Gnome doesn't already have one), but providing a uniform interface that all GLib-based applications and libraries can use to find their resources regardless of which platform they're running on. Gtk simply needs to use that interface. At the app level, it's up to app developers to use the interface (and to select dependencies that do, too) if they want good portability.

Regards,
John Ralls