App Bundles

[Brian J. Tarricone]

On 08/26/2009 03:25 PM, Stephen Paul Weber wrote:
> In some contexts, app bundles (where all files for an application live in
> some folder, like on MacOS) are useful.  I've been thinking recently about
> an app bundle layout that is based on freedesktop specs and also not
> gratutitously different from the MacOS layout.  I share it here because
> someone might like the idea, or have an even better one.

Cool!

> An app bundle is any directory containing a Contents folder which contains
> an app.desktop file.

This might be a bit too general.  Why not define a standard extension
(such as .app) for the directory name like MacOS X does?

> The icon for the bundle is the icon for the desktop entry.  Icons should be
> searched for first in Contents/Resources and then according to the rest of
> the icon theme spec.

I'd prefer to have an 'icons' subdir (or something) inside Resources
that has a directory structure that complies with the icon theme spec.
Of course that makes for another MacOS X incompatibility, though I guess
it's already incompatible since Mac app bundles use the .icns format,
which I doubt gtk or qt support natively.

> The arch string for a system is:
> 
> `uname -s  | tr '[:upper:]' '[:lower:]'`-`uname -m`

This might be something you'd choose not to support, but: whether or not
you can run the app also depends on the C++ ABI in use, and possibly
other things.  There's a discussion somewhere in the archives for this
list about XDG_LIB_HOME that might be illuminating.

> uname -m should be normalised (i\d86, x86 => i386.  x86_64 => amd64)

I'd agree to i386 normalisation, but x86_64 is the canonical arch name
(at least by GNU standards), so we should use that.  I'd imagine
nowadays there are as many (if not more) Intel x86_64 setups than AMD, even.

> The environment should be such that the current working directory is /

Probably should use $HOME, or even somewhere in the bundle itself.

> the program has been invoked using it's absolute path (such that dirname $0
> becomes the absolute path to the program).

I like this -- greatly simplifies finding stuff included in the bundle,
regardless of what $PWD is (or ends up being changed to by the app).

> The primary executeable should be encouraged to prepend `dirname
> $0`/../Resources to XDG_DATA_DIRS in order to find its data.

Sure... assuming that the app will store its data in an app-specific
subdir of Resources/, this will also work for installs of the app in a
"normal" FHS-compliant manner.

> To make this app bundle compatible with MacOS, the following must be
> performed:
> 
> ln -s darwin-i386 MacOS
> 
> The content of the Exec line with % codes stripped is CFBundleExecutable.
> Icon and Name may optionally also be extracted.
> This data put into Info.plist in the correct XML format.

Presumably this would be done automatically by whatever tool is written
to build the bundle file.

In general the problem with app bundles on an OS like Linux is that it's
difficult to be sure dependencies are available, and if they are, it's
hard to tell if they're compatible.

That, plus the fact that the usage model for most Linux distros pushes
users to prefer installing apps via their package manager, tends to make
app authors hesitant to building or distributing Linux binaries at all.
 Instead they rely on distro package maintainers to pick up their app
and package it.  While this works decently well, there's often a lag,
especially for less popular apps.

But all of these things can be worked around to some extent.  There are
ways to build your app so that it makes use of lowest-common-denominator
features, and you can do things like build against the oldest version of
the gtk+ headers that you support.

Binary relocatability is also an issue based on hardcoded path names.
With XDG_CONFIG_DIRS and XDG_DATA_DIRS this is alleviated somewhat, but
there could still be issues with, say, private shared libraries shipped
in the bundle, whether the intention is to link with them at
compile/link time, or open with dlopen().

These issues aren't intractable, but it would help uptake if they could
be solved or at least made easy to deal with in one place.  Also a
bundle generation tool would be needed... the idea being that you want
making a bundle to be a trivially easy step that requires very little
work for the app author.  While personally I think autopackage is/was a
cool project, it clearly has not gained the following its authors hoped.
 An app bundle spec is probably doomed to the same fate unless it's
dirt-simple to set up bundle creation.

Of course there's also the other part of it: getting support into major
desktops.  You'll want to be able to display the app bundle directory as
an executable file in your file manager, and, for command-line users,
you'll want a simple bundle-open command or something.

Also someone should look at security issues: recently (and not so
recently) there have been security concerns raised over how .desktop
files are handled in file managers and on desktops.  I imagine similar
concerns would be raised about app bundles.

Anyway, I do think this is a worthwhile idea, and fills what I sometimes
think is a big hole in making Linux more mainstream-accessible: the
ability to download an app from the app author's website and run it as-is.

	-brian