App Bundles

[Stephen Paul Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> > 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?

That's an option, if people thing the above requirement is too loose.

> > 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.

MacOS actually supports formats besides icns for the app icon.
I think I agree about the 'icons' subdir.  The generated Info.plist could
then be made by a script that resolves the path inside Resources according
to spec and puts the whole relative path in (which I believe should work).

> > 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.

XDG_LIB_HOME? How would that differ from LD_LIBRARY_PATH?

> 
> > 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.

This convention was actually adapted directly from the convention for Debian
package arch strings, and that is where the 'amd64' historical value came
from.

> > The environment should be such that the current working directory is /
> 
> Probably should use $HOME, or even somewhere in the bundle itself.

Hmm, fair enough.  I think MacOS starts from /, but it's unlikely that apps
depend on that.

> > 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).

Yes.  That's basically how all discovering the location of stuff in the
bundle works on MacOS.

> > 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.

Yes.

> > 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.

Yes.

> 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.

This problem is the same on all OSs.  It's just on linux we have a solution
(package managers) and so we think of it as a much bigger problem.

App bundles would have to either contain their libraries (gross, but
possible) or use one of the other manual-resolution techniques from the
Windows world.

I didn't really intend to specify how dependencies are handled, only the
format for bundling.

> 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.

Really?  While I prefer versions from package managers, I get binaries from
websites not in package form all the time.  They're usually just a tar that
you have to put in some specific place.  Sometimes they're relocateable,
which is nice.

> 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().

LD_LIBRARY_PATH is the equivalent of XDG_DATA_DIRS for shared libraries.
Many people hate it because of performance issues in searching more than one
place for libraries.

> 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.

I'm strongly considering a script that converts any *.deb to an app bundle.
It would have to assume that the contents of said package are relocateable
(no way around that), but assumedly this tool would be used by devs.  It
would have a switch to resolve dependencies manually and include them, or
not.

> 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.

I actually have the start of such a bundle-open command, but yes, the big
hurdle would be getting GNOME and KDE to support the format.

> 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.

Indeed.  MacOS is the only OS that really has such a feature these days, but
still, it's a good feature to have.

- -- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKldO5AAoJENEcKRHOUZzexf0P/06S0+oA2C/1YIMPvrjfqvw6
x5QpevcizjwrQOEzlMEqiN8s0Y+qU7Uz4ZGOHmAzuIK7xPUaKKlhPAwaVafGNPma
BeR6OTMaMUXkEInDICf5saDalRj50AKREXjQnXh84RaJin45Jxf/odMAgfzX2tFh
Wa+5xz+TDAFvh29ARGvpOdIQH15aix8qIvhK0z8r84O4z+f6C0gD3ie+zjNORY6J
Jm/HQNE+BTykUtR+51Ofk05RNC9oLzTve1SW7QrB6vxM+H2oM2xLjcyoIQsje55x
i5joq1ggUSRbepFqu8iSn9g23y/6L60KqXmZY7qNu/X/fuaC66NCk0PY3JDT5t+7
WG/ljOkJSJmMGvvntze5/9+Zddk6FU/WMyflkB9EJn1r3GeL2f3Eww3Td4XR6vFs
V1gBfnlHjzfNYr8maZc12tBFKfZZ5Ngy4MqEBxmMejghXhEXoYayCKuOA3hbyIR+
ebgUK+d6bJpd/OxJtz/K4ZVt+bOwCFuHaXnc0yU0ZE19BKZ5YnTE8TvDNElHJaLq
4keZ63AzFziGu1+cXLKnYgm0e7HgphBqZKlxQZwvPR7dS9qhVHHZXTQX49b/EPyx
TLiN1ki5YZjdRWhDFREUF6Wdh4rgvMNHA6FB0QtcmlNLcAFRK6aRW+D0zOrQGNH8
O2dxJAz2ahwboc4RJFIX
=+LeL
-----END PGP SIGNATURE-----