App Bundles

[Brian J. Tarricone]

On 08/27/2009 06:12 AM, André Gillibert wrote:
> "Brian J. Tarricone" <bjt23 at cornell.edu> wrote:
> 
>> If Foo-app looks for its plugins in $XDG_PLUGIN_DIRS/foo-app, and
>> Bar-app looks for its plugins in $XDG_PLUGIN_DIRS/bar-app, then there
>> can never be any conflict, even if both of them are set up as bundles
>> and one launches the other with their "private" bundle path in
>> XDG_PLUGIN_DIRS.
> 
> Okay, that solves the issue. I thought the application would search its plugins in "$XDG_PLUGIN_DIRS/" which would have made all plugins of all applications stored in the same directory.

No, no, I'm still thinking of something very similar to
XDG_CONFIG_DIRS/XDG_DATA_DIRS.  The spec requires that subdirectories of
those directories be used.  So while the default XDG_DATA_DIRS is
/usr/local/share:/usr/share, the default XDG_PLUGIN_DIRS would probably
be /usr/local/lib:/usr/lib.

>> No, it doesn't have everything it needs.  It may have all the
>> *information* it needs, but it doesn't know to do anything with it
>> without extra work.  Even if that extra work is minimal, you still have
>> to convince the app author that doing that work is worthwhile. 
> 
> Since most current applications do use absolute paths, if you don't want to touch application's souce code, then, you've to run them in a chroot'ed environment. There's no other way.
> 
> What's different with XDG_PLUGIN_DIRS! You've to convince the author to compute the path from this env var! How is that easier than doing it from argv[0] ?
> Moreover, from your first post I assumed you expected applications to use argv[0] to find their own data files. So, why treating data and plugin files differently?
> 
> Ok, now I see a compelling reason:
> XDG_PLUGIN_DIRS would be to let people use plugins not bundled with the application in addition to plugins bundled with the application, the former being kept in a /usr/share/plugins/appname directory.

Right.  My idea here is that yes, of course apps would need to change
code to use XDG_PLUGIN_DIRS, just like they had to for XDG_CONFIG_DIRS
and XDG_DATA_DIRS.  But the difference from using argv0 is that you get
other benefits with XDG_PLUGIN_DIRS, so you're not trying to convince
app authors to support something special *just* for bundle support.

> In short, the following approach seems good.
> 1) Bundled applications would be directories containing a standard file system hierarchy with ./usr/lib ./usr/bin, ./usr/share, etc.

Eh, not sure we really need this, but it would make building bundles a
lot easier.  Stephen's original idea was to make our bundle spec look
like MacOS X's bundle spec to avoid gratuitous incompatibilities, which
is a goal I agree with.

> 2) When launched without path prefix, the application would assume the "base directory" is /, otherwise it would be the directory prefix with the final usr/bin truncated.

Well, I think to be safe we should require that the bundle is *always*
launched with an absolute path.  This isn't hard to do, though it does
mean that you can't correctly run the app just by finding the binary in
the bundle and running it.

A bundle launcher would need to take care to do things like:

1. Set up XDG_CONFIG_DIRS, XDG_DATA_DIRS, and XDG_PLUGIN_DIRS.
2. Find the absolute path of the app inside the bundle and launch it.

> To make that easy, a simple library providing a getBaseDirectory() function would be created.

Well, a new library isn't needed.  Glib and libxfce4util already has
functions to determine the other XDG basedirs, and I assume Qt has
something similar.  We'd just add XDG_PLUGIN_DIRS to that.

> 3) When loading a data file, it would use this base directory as prefix.

No, it would use the same method it does now that follows the XDG
basedir spec.

> 4) When loading a plugin, the application would use a getPluginDirectories() enumerator function and its app-name suffix.
> I see two possible implementations to this function:
> 1. Simply list XDG_PLUGIN_DIRS directories, requiring desktop environment to add the base directory to this plugin dir when launching the bundled application.
> 2. Or, list XDG_PLUGIN_DIRS directories plus getBaseDirectory()/usr/plugins.
> I think the later is better, as both implementations have the same application interface, but the former has a more complex interface to the desktop.

Ok, now I'm confused -- what is this "base directory" and why is it
necessary?

> This simple command:
> cp -r /path/to/bundle/* /
> Would install the bundle application.

Well, more like

cp -r /path/to/bundle.app /wherever/the/user/wants

> Launching the application, bundled or unbundled would be as simple as giving its full path on the command line. When installed, you could also type its name without prefix.
> e.g.
> 
> /path/to/bundle/usr/bin/nice_app
> /usr/bin/nice_app (if it has been copied to /)
> nice_app (if it has been copied to /)

This kinda defeats one of the purposes of the bundle: to hide all the
details of how it works from the user, and just present it as a single
unified package that you can run.  Bundles aren't primarily intended for
users who use the command line; they're intended for users who just want
to download an app from a website and double click on it to run it,
without needing to do any other setup.  (Not saying command-line users
*can't* use bundles, which is why we'd write a simple bundle-open
command that does the same things that a file manager or desktop manager
would do when the user double clicks the bundle.)

> To make bundle applications nicer, as you suggested, a desktop file should be provided.
> Where?

I don't think the intention here is to install .desktop files outside
the bundle.  There isn't really a way to do this because bundles are
relocatable: if the user moves the bundle, then the .desktop file
becomes invalid.

> Maybe in ./usr/share/applications/nice_app_name.desktop
> But that would prevent the application to have more than one desktop file...
> Or maybe simply ./app.desktop as you suggested, but that would make installing the bundle a bit more complex than cp -r.
> There may be some better way.

Well, as Stephen's original proposal stated, there will be a .desktop
file inside the bundle that actually determines the program (inside the
bundle) that gets launched, and also provides a display name, icon, etc.
 The desktop's system menu won't know about this .desktop file, and I
think that's fine.  These are intended to be transient apps that aren't
necessarily permanently installed.  We might want to consider system
menu integration at some point, but I don't think that's necessary to
get the base idea working.

	-brian