Re: Glib resource framework
On Thu, Dec 29, 2011 at 2:43 AM, Enrico Weigelt weig...@metux.de wrote: Okay, we're talking about ways to deploy an arbitrary binary package (built somewhere else, fully out of the scope of the users's distro) to an arbitratry location. But: WHY ? What is the problem that should be solved by that ? because this is the 21st century in which (1) applications consist of more than a binary executable (2) users like easy-to-install-and-remove programs (3) ISV's like ways to provide users with easy-to-install-and-remove-programs (4) ISV's need to know that the versions of the library they are linked against is the correct one (5) applications written using C++ have a whole additional set of problems, which i will not detail here (6) some ISVs do not want their software to be primarily distributed by dozens of per-distro packagers. The splintering of linux into dozens of different distros, all with their own particular foibles, means that its much easier to approach things from a bundle perspective. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Thu, Dec 29, 2011 at 01:43, Enrico Weigelt weig...@metux.de wrote: That's what I already apprehended ... ;-o What's the exact reason for loading them dynamically ? As a non-committer, reading this thread, I saw the reasons as this: It was coded this way initially, it's painful to change it, so nobody has changed it. Furthermore a lot of the build process has grown the same way, so changing it is even more painful. Nobody has expressed a reason to disallow such a change; merely that it is hard to overcome the inertia of what has already been coded. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: What is the problem that should be solved by that ? because this is the 21st century in which (1) applications consist of more than a binary executable I dont see a problem in this point. Actualy I'd prefer using even more separate binaries (and processes) for lots of architectural reasons. (2) users like easy-to-install-and-remove programs This is what distros and their packages are for. All the distros have their different use cases and audiencences and therefore valid reasons for their different approaches. (eg. Gentoo is not so different from Debian, just because they can, but because of the completely different scope) (3) ISV's like ways to provide users with easy-to-install-and-remove-programs That's what the distros's packaging toolchains are for. If upstream does a good job (clean architecture and codebase), the actually packaging efforts are quite minimal. (4) ISV's need to know that the versions of the library they are linked against is the correct one Proper dependencies and maybe additional checks in the configure stage (assuming that's *really* necessary) handle this. (5) applications written using C++ have a whole additional set of problems, which i will not detail here Well, I'm really interested in hearing them in detail. (6) some ISVs do not want their software to be primarily distributed by dozens of per-distro packagers. Simply install your bundled apps into some clearly specificed prefix (eg. /opt/my-app-name) The splintering of linux into dozens of different distros, all with their own particular foibles, means that its much easier to approach things from a bundle perspective. Not really. Perhaps on a quick look, but not in long terms. With those bundles you take the burden of many things that are normally the job of the distros. In the longer run, it just moves the problem, not solving it, and you'll also have to maintain all the bundled 3rdparty-packages. (I've seen a lot of projects where exactly this caused big problems, which just happened to become visible with a few years delay, but then became really ugly) Please be careful when comparing with the MacOs world - they have a really carefully engineered homogenous environment (which also imposes several constraints on the whole system architecture to make this all work), designed top-down. Completely different situation from the GNU world. All of this we're talking about right now are build and depolyment issues. Trying to solve them in an helper library like glib or gtk is fighting in the wrong place. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Hub Figui?re hfigui...@teaser.fr schrieb: -performs some changes to ldd to support linkage relative to the executable. I'm sure we can work around it with a shell-script wrapper; wrapper that might also be needed to support other OS, but I do believe it would be beneficial to investigate that possibility. ACK, that would be the quickest and easiest solution. And I have a very strange feeling with changing ldd's lookup semantics, beginning with serious security considerations. But: if the application bundle should be entirely self-contained, why using dynamic linking (of non-system-libaries) at all ? Actually, I'm entirely not convinces of the concept of self- contained applications at all. Sooner or later they will have to integrate/communicate with some other application (eg. beginning with tiny things like adding some menu entry or icon), and this will require some top-down coordination. And that's exactly the point where distributions come in. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: * as you note LD_LIBRARY_PATH takes care of this just fine, via a startup shell script. This covers just about all the *nix family. OS X requires nothing, which leaves Window where I have no idea. Maybe it's just a matter of fixing the libc on Windows, to support relative lookup pathes, etc. But btw: do we really need dynamic linking at all here ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Bastien Nocera had...@hadess.net schrieb: Em Thu, 2011-12-22 às 08:49 +0100, Enrico Weigelt escreveu: * Hub Figui?re hfigui...@teaser.fr schrieb: Maybe we could actually support bundles like it is done on MacOS. ./configure --prefix=foo ? It doesn't magically make libraries and binaries relocatable. Install it into some specific, standardized prefix and let process-local namespaces (eg. chroot+bind-mounts, etc) do the rest. Or simply install each application into its own namespace, similarily to package namespaces known in the Java world. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, Dec 28, 2011 at 3:02 AM, Enrico Weigelt weig...@metux.de wrote: ACK, that would be the quickest and easiest solution. And I have a very strange feeling with changing ldd's lookup semantics, beginning with serious security considerations. But: if the application bundle should be entirely self-contained, why using dynamic linking (of non-system-libaries) at all ? the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Actually, I'm entirely not convinces of the concept of self- contained applications at all. Sooner or later they will have to integrate/communicate with some other application (eg. beginning with tiny things like adding some menu entry or icon), and this will require some top-down coordination. And that's exactly the point where distributions come in. no, this is where defined APIs like the ones from freedesktop come in. or, by illustration with OS X, where the specification of the Info.plist file comes in. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: But: if the application bundle should be entirely self-contained, why using dynamic linking (of non-system-libaries) at all ? the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Why not, exactly ? Actually, I'm entirely not convinces of the concept of self- contained applications at all. Sooner or later they will have to integrate/communicate with some other application (eg. beginning with tiny things like adding some menu entry or icon), and this will require some top-down coordination. And that's exactly the point where distributions come in. no, this is where defined APIs like the ones from freedesktop come in. You're assuming, any interaction between applications allowed is what's specified in that APIs. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, Dec 28, 2011 at 9:20 AM, Enrico Weigelt weig...@metux.de wrote: * Paul Davis p...@linuxaudiosystems.com schrieb: But: if the application bundle should be entirely self-contained, why using dynamic linking (of non-system-libaries) at all ? the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Why not, exactly ? because quite a lot of GTK is dynamically loaded even if the basic libraries themselves are statically linked. and because the entire stack has a build system that pretty much assumes the the use case is dynamic linkage. this could no doubt be changed but nobody has ever stepped up to clean it up. no, this is where defined APIs like the ones from freedesktop come in. You're assuming, any interaction between applications allowed is what's specified in that APIs. if you want much more extensive integration, you're talking about desktop environments and apps written specifically to tightly integrate with them. as an ISV, i'm not really that interested in such things. i don't control nor do i want to control what DE's my users have, and i don't want my app dependent on the sort of concepts that DEs are now moving towards apart from a very limited common subset (e.g. presence in standard lists of applications, icons). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Why not, exactly ? because quite a lot of GTK is dynamically loaded even if the basic what exactly is loaded dynamically, and why is the necessary ? libraries themselves are statically linked. and because the entire stack has a build system that pretty much assumes the the use case is dynamic linkage. how exactly ? no, this is where defined APIs like the ones from freedesktop come in. You're assuming, any interaction between applications allowed is what's specified in that APIs. if you want much more extensive integration, you're talking about desktop environments and apps written specifically to tightly integrate with them. I'm not just talking about desktop integration. What, eg., with integration with certain system resources, daemons, system-wide configuration, etc, etc ? as an ISV, i'm not really that interested in such things. i don't control nor do i want to control what DE's my users have, and i don't want my app dependent on the sort of concepts that DEs are now moving towards apart from a very limited common subset (e.g. presence in standard lists of applications, icons). Sure. Therefore you need some easy way for passing certain information to the DE, take for example menu entries or desktop icons. a) explicitly supporting a wide range of DE's, eg. by simply installing the necessary files to the DE's standard locations. - build time issue, can be easily put into an separate build helper tool b) have an extra system tool, which translates an abstract (DE-independ) source to the DE-specific files c) convince the individual DE-developers to directly support such abstract descriptor files But this doesn't really require things like binary relocation. I'm still not conviced. So, please let's go to the root questions: What are the exact problems you're trying to solve with binary relocation ? What are the desired use cases ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, Dec 28, 2011 at 10:03 AM, Enrico Weigelt weig...@metux.de wrote: * Paul Davis p...@linuxaudiosystems.com schrieb: the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Why not, exactly ? because quite a lot of GTK is dynamically loaded even if the basic what exactly is loaded dynamically, and why is the necessary ? * image file format loaders * font format handling * theme engines * various other modules libraries themselves are statically linked. and because the entire stack has a build system that pretty much assumes the the use case is dynamic linkage. how exactly ? try it. you'll see. its been a long time since i wasted time on this. I'm not just talking about desktop integration. What, eg., with integration with certain system resources, daemons, system-wide configuration, etc, etc ? neither GTK nor any DE needs to do anything about integration with things that are not part of GTK nor a DE. as an ISV, i'm not really that interested in such things. i don't control nor do i want to control what DE's my users have, and i don't want my app dependent on the sort of concepts that DEs are now moving towards apart from a very limited common subset (e.g. presence in standard lists of applications, icons). Sure. Therefore you need some easy way for passing certain information to the DE, take for example menu entries or desktop icons. freedesktop covers all this. So, please let's go to the root questions: What are the exact problems you're trying to solve with binary relocation ? i don't even know what you mean by this term at present. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: what exactly is loaded dynamically, and why is the necessary ? * image file format loaders * font format handling * theme engines * various other modules That's what I already apprehended ... ;-o What's the exact reason for loading them dynamically ? I'm not just talking about desktop integration. What, eg., with integration with certain system resources, daemons, system-wide configuration, etc, etc ? neither GTK nor any DE needs to do anything about integration with things that are not part of GTK nor a DE. Well, but individual applications might need to. Think of stuff like socket pathes to certain daemons, etc. Runtime dependencies are a bit more than just shared objects ;-o Sure. Therefore you need some easy way for passing certain information to the DE, take for example menu entries or desktop icons. freedesktop covers all this. Okay, let's take this example: http://standards.freedesktop.org/menu-spec/latest/ It expects the menu entries in a specific location (beyond the prefix set by environment). AFAIK, the prefix itself isn't explicitly specified (just some suggested default), so it's dependent on the actual system configuration. Now we've got a problem with fully-relocatable applications: How does the DE know where's all these applications's installation prefixes are ? So, please let's go to the root questions: What are the exact problems you're trying to solve with binary relocation ? i don't even know what you mean by this term at present. Okay, we're talking about ways to deploy an arbitrary binary package (built somewhere else, fully out of the scope of the users's distro) to an arbitratry location. But: WHY ? What is the problem that should be solved by that ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Matthias Clasen matthias.cla...@gmail.com schrieb: If an app is in a single file, it can be copied and removed easily. The same can be easily done with an directory. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
Em Thu, 2011-12-22 às 08:49 +0100, Enrico Weigelt escreveu: * Hub Figui?re hfigui...@teaser.fr schrieb: Maybe we could actually support bundles like it is done on MacOS. ./configure --prefix=foo ? It doesn't magically make libraries and binaries relocatable. I tried reading this thread and ended having to read your dismissive, and usually utterly wrong, rants. Just don't post, it'll save me some reading, and spare your blushes. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, 2011-12-21 at 15:07 -0800, Hub Figuière wrote: On 21/12/11 02:47 PM, Alexander Larsson wrote: I think this could be very useful in many places, for instance to ship built-in css files, gtk builder files, win32 theme images etc in a way that still makes libraries relocatable (and avoids potential for runtime errors due to not found files). Maybe we could actually support bundles like it is done on MacOS. The idea of compiling data into a binary file give me a blast from the past from the MacOS 9 days. See: http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Alexander Larsson al...@redhat.com schrieb: Maybe we could actually support bundles like it is done on MacOS. The idea of compiling data into a binary file give me a blast from the past from the MacOS 9 days. See: http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/ Congratulations. You've copied one of the really worst concepts of the windoze world. Desktop distributions like Fedora or Ubuntu work remarkably well, and have a lot of applications packaged. However, they are not as reliable as you would like. #1 Fedora always has been bad (IIRC just SuSE is even worse). #2 Ubuntu is probably one of the most stable distros around there, we're successfully using it for missing critical systems with millions of users. Do you really think that a single application development team can ensure application *and* system stability without close coorporation with the distro maintainers ? Most Linux users have experienced some package update that broke their system, or made their app stop working. Yes, especially when taking untested upstream packages directly. (speaking of which: certain upstreams are even still stupid enough for using AC_TRY_RUN, etc, ...) Linux users quickly learn to disable upgrades before leaving for some important presentation or meeting. Sane distros don't enable this on default. Every package installs into a single large system where everything interacts in unpredictable ways. For example, upgrading a library to fix one app might affect other applications This is exactly one of the major points what professional distros and their quality engeneering mechanisms are for. Installing software from untrusted sources always brings high risks. Package installation modify the system at runtime, including running scripts on the users machine. This can give different results due to different package set, install order, hardware, etc. Most of those problems come from bad upstreams or distro maintainers. Installing applications not packaged for your distribution Anyone yet had the idea that this might have some vaid reasons ? Maybe the distro maintainers consider that particular package not stable enough ? Installing a newer version of an application that requires newer dependencies than what is in your current repositories Blame the bad distro maintainers. Keeping multiple versions of the same app installed Why, exactly ? Keeping older versions of applications running as you update your overall system Such problems come from bad upstream or package maintainer. I imagine a system where the OS is a well defined set of non-optional core libraries, services and apps. Plan9 ? The platform is a small set of highly ABI stable and reliable core packages. It would have things like libc, coreutils, libz, libX11, libGL, dbus, libpng, Gtk+, Qt, and bash. Yeah, dbus, libpng, gtk+ and qt considered highly ABI stable. I just had to double-check the calendar, if I missed a few month and we've got April 1st again. All applications are shipped as bundles, single files that contain everything (libraries, files, tools, etc) the application depends on. Essentially dropping the concept of shared libraries. Bundles are self-contained, so they don't interact with other bundles that are installed. Why not just using containers or at least chroot's for that ? Installing them is as easy as dropping them in a known directory. Bypassing all fundamental security considerations. Then the bundle file itself is mounted as a fuse filesystem in a well known prefix, say /opt/bundle. Congratulations on the performance drop. Why not just using chroot's for that and leaving the rest as it is ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Wed, 2011-12-21 at 17:47 -0500, Alexander Larsson wrote: I just finished a one-day hackathon to add a resource framework to glib, its somewhat working if not very polished. Its in the resources branch in glib git. I think this could be very useful in many places, for instance to ship built-in css files, gtk builder files, win32 theme images etc in a way that still makes libraries relocatable (and avoids potential for runtime errors due to not found files). Feedback on the concept and the code welcome... Time to leep... Ok, I pushed a few changes to the API and a few new features/fixes: * On linux the resources end up in separate named readonly data sections: readelf -S gio/tests/.libs/resources ... [16] .gresource.test2 PROGBITS 00402d38 2d38 00ac A 0 0 8 ... This means you can extrace resources from existing binaries. * GBytes is used in the APIs where useful * Support for optionally compressed resources Note: You can only stream these, not get at the underlying bytes * Support for locale specific resource alternative You can replace individual resources based on the current locale * Guarantee zero termination of the raw data you get when looking up data I think this is in a better state than yesterday. The outstanding issues i see are: * Documentation * Test the constructor macros on more compilers/OSes * We should modify gvdb so that it groups all the key strings used for the hash lookups consecutively, instead of mixed with the data. This would mean touching less pages during lookup. * Figure out how to handle unloading This last one is the hardest one. Right now i'm using g_atexit() from the constructor. This means that on at least win32 and glibc = 2.2 we'll get called when the module is unloaded, but on other arches we might not be called until the process terminates. Both of these create issues. If its called on exit we will crash on exit due to the call into nonexisting code. But we will also be keeping registered global resources that point into data that doesn't exist anymore. If we get called on module unload things a much better, we will generally not crash, and we will properly unregister the resources for the module. However, any outstanding data (GBytes or GInputStreams) from the resource will suddenly see their backing go away. We could possibly keep track of these and neuter the objects, but if you have e.g. a raw pointer to the data then there is no way to get notified of this. I'm not sure what the best approach is here. The later problem seems avoidable by not keeping data around for too long, but the problems with atexit being broken is hard to work around. Is there some other alternative though? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On 22/12/11 03:18 PM, Paul Davis wrote: apple gave up the whole package resources into binary blobs that are sort of like files but not really thing about 10 years ago, after 10 years of experience with it. i'd like to think we could learn from their experience. The whole resource business was designed in the early 80s to deal with a structured set of data load from a slow mass storage (floppy disk) on a very constrained memory (128kb). That lead to the resource manager on Macintosh. It was even used to store the actual executable code. Other times, other constrains. But it was fragile (you could easily corrupt it) and sometime would cause crashes. The package bundle we see on MacOS now is inherited from NeXT and Apple started using it in MacOS 10.0 in 2001 instead of resources. The only major difference between a package bundle and things installed in a prefix is that the package bundle is all self contained. It does not prevent from using a package manager but it make it less a necessity[1] Also, unlike the proposed binary resource this would work with applications written in Python, Ruby, etc. where all the files could be located in that self contained package bundle. Like, say, the gnome-shell. This is already done at large on MacOS. Supporting this concept would involve the following changes: -API in gio to access bundle and content so that application developer can write relocatable software. They can be designed to work either way. -change in the autoconf macros to allow dealing with package bundles easily. -change in Nautilus to deal with package bundle, and possibly the shell and other core components that needs to know about it -fix gsettings[2] -performs some changes to ldd to support linkage relative to the executable. I'm sure we can work around it with a shell-script wrapper; wrapper that might also be needed to support other OS, but I do believe it would be beneficial to investigate that possibility. Ideally there would be a spec written so that it becomes cross-desktop so that KDE Software Collection could benefit from it the same way. Hub [1] I'm no advocating to drop package management here. [2] This is left as an exercise to the reader to guess what needs fixing. I have some ideas, but tl;dr ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
On Thu, Dec 22, 2011 at 7:07 PM, Hub Figuière hfigui...@teaser.fr wrote: Supporting this concept would involve the following changes: -API in gio to access bundle and content so that application developer can write relocatable software. They can be designed to work either way. there is no need for an API in gio. everything that is needed to do this is already in place except for * there are some complications using Pango and/or Fontconfig as relocatable libraries. these are not insurmountable, just ugly to handle. * the current gmodules/gsettings stuff does not allow overriding the location where gmodules are located at run time with an environment variable. this is easy to fix, but right now it means that gmodules will find (and load) modules outside the bundle. -change in the autoconf macros to allow dealing with package bundles easily. * personally, i could care less about autoconf. there are no changes required to build the the gtk stack so that it is ready for environment variable based relocation. if some app developers want to wrestle with using autoconf to build bundles, then sure. -change in Nautilus to deal with package bundle, and possibly the shell and other core components that needs to know about it * unless you plan to create an equivalent of Launch Services and OS X's open(1) command, this seems barely necessary. its entirely possible for a bundle to make itself appear on the desktop and/or menus without any interaction with nautilus or any kind of shell. * perhaps you want users to get some special protected view of a bundle. fair enough but i've always found this quite irritating on OS X where Finder by default hides bundle contents. -performs some changes to ldd to support linkage relative to the executable. I'm sure we can work around it with a shell-script wrapper; wrapper that might also be needed to support other OS, but I do believe it would be beneficial to investigate that possibility. * as you note LD_LIBRARY_PATH takes care of this just fine, via a startup shell script. This covers just about all the *nix family. OS X requires nothing, which leaves Window where I have no idea. Ideally there would be a spec written so that it becomes cross-desktop so that KDE Software Collection could benefit from it the same way. * there's nothing GNOME-ish required to build bundles. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Glib resource framework
I just finished a one-day hackathon to add a resource framework to glib, its somewhat working if not very polished. Its in the resources branch in glib git. I think this could be very useful in many places, for instance to ship built-in css files, gtk builder files, win32 theme images etc in a way that still makes libraries relocatable (and avoids potential for runtime errors due to not found files). Feedback on the concept and the code welcome... Time to leep... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
