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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
