On Fri, Apr 15, 2011 at 11:06 AM, Alexander Larsson <al...@redhat.com> wrote: > On Wed, 2011-04-06 at 23:34 +0200, Kean Johnston wrote: > >> Last, but by no means least, is the reliance on "compiled" files, like >> compiled schemas (or in the case of Gtk, icon caches). On UNIX systems >> where things are installed in a universally-accessible location, this isn't >> a problem, but on Win32, where multiple applications could all include >> their own private copies of the DLL's, this is a problem. Fixing this is a >> bit tricky but very doable. Windows does provide two places that are >> predictable and universally accessible: the registry, and %ProgramData%. >> The registry is a poor choice except perhaps for location files inside >> %ProgramData%. The registry is slow, and also imposes some severe >> limitations on key sizes etc. This can be very easily addressed by >> compiling Glib with LIBDIR set to something like "%ProgramData%\Glib\2.x" >> and ensuring that functions like g_file_get_contents() or g_open() all call >> ExpandEnvironmentStrings() on Win32. This is also a relatively small change >> and doesn't change any existing API's (although on Win32 it will have a >> behaviour change). > > Things like this is a problem on unix too, as it makes relocatable > apps/libs hard. > > I've long had this dream of perfectly relocatable gnome libraries/apps > where the executable file itself contained all the information it needs. > Relocating something like that is trivial (LD_LIBRARY_PATH is all that > is needed). > > The plan I have is to add a resource system to gio, similar to > http://doc.qt.nokia.com/4.0/resources.html where you describe the > resources in a file, and during the build this gets compiled and linked > into a read-only section in the library/executable. Then we'd have an > API that allows easy lookup of named resources (in a combined namespace > for all libraries in the app) such that you can easily get inputstreams > to the data or direct pointers to the data. > > This allows all kinds of nice extras, like transparent compressed > resources (although these will not allow direct pointers) and > locale-specific versions of resource files. It will also ensure that all > users on the system map the same resource data instead of loading it in > each process. > > Another aspect is translations. I've been thinking a bit about ways to > relocate these. We could internalize a copy of gettext into glib and > modify it to be able to read mo files directly from the binary. Of > course, this would make the library kind of large, but not larger than > the current total package size. It would be harder to strip out unused > translations in an installation though, but I have some ideas that can > solve this. > > Introspection data could also be made part of the shared library itself, > rather than a separate file. It would just be a custom elf section. > > 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. Damjan Jovanovic _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
