Re: Glib resource framework

[Paul Davis <paul linuxaudiosystems com>]

On Thu, Dec 22, 2011 at 7:07 PM, Hub Figuière <hfiguiere 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.