App Bundles

[Alberto Ruiz]

Brian J. Tarricone wrote:
> 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?
>   

There is also a performance penalty, if you don't use an extension on
the folter, a file browser will need to poke every single directory to
check if there's a app.desktop file inside. Whereas, with a folder name
with a extension, like folder.app, we can have a special mimetype to
handel this. Once that is detected, *.desktop files would be detected.
>> 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.
>>     
Why don't we stick to XDG data dirs spec inside of the bundle and we
treat it as an extended .local/ ? having share/icons for icons and that
sort of stuff.
> 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.
>   
Heh, exactly.
>> 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.
>   
Yeah, things can gete very hairy. On the other hand, people should
bundle as many libs as they should to get their app to run across systems.
> 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).
>   
Agree.
>> 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.
>>     
>
>   
I don't think we should make the budle compatible with MacOS to be
honest, I mean, we have plenty of XDG standards that covers most of the
stuff already and I think we should reuse them.
> 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().
>   
That's not an issue as long as there is a .app launcher that takes care
of the $0 thingie.

In Windows systems, there's a call to get the path of the binary being
executed, this is what Gtk+ uses to allow itself to be relocatable on
Windows systems IIRC. We could have an libxdg-bundle with facilities for
this kind of stuff.
> 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.
>   
I've been discussing this with Alexander Larssonn and some KDE guys,
Alex is all for the idea (he's the Nautilus maintainer), and I already
have some patches to enable Gtk+ to have subclases of the inode/folder
MIME type, I think both desktop would adopt something like this as long
as a sane standard is proposed here.

> 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.
>   
I don't think there's a difference between the normal .desktop and the
bundles in this regard, so it doesn't make the problem worse.
> 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
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>