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. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc al...@redhat.com alexander.lars...@gmail.com He's a short-sighted amnesiac cop with a secret. She's a cynical kleptomaniac lawyer in the witness protection program. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list