On Apr 15, 2011, at 6:01 AM, 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.

ISTM that it's cleaner and more broadly applicable to use something like 
binreloc (sadly no longer being developed, but widely copied and used in unix 
applications), where the paths to various resources can be configured at 
runtime in whatever way is appropriate for the system. We do this with Gnucash 
and it works well, though some of our dependencies don't and we have to resort 
to hacks to work around their limitations. 

Regards,
John Ralls
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to