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?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
al...@redhat.com alexander.lars...@gmail.com
He's a scarfaced pirate werewolf on a search for his missing sister. She's a
ditzy extravagent queen of the dead with an evil twin sister. They fight
crime!
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
