alberto.ruiz at codethink.co.uk
Fri Aug 28 03:23:40 PDT 2009
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.
>> 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.
>> 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).
>> 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
>> 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.
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg