How are portable apps called by the system when needed (eg file association)?

There are a fe开发者_JS百科w implementations of portable apps in Linux, but it seems that all Mac OS X apps are portable. Since Mac OS X completely embraces this model, I'm assuming they already have a solution to this problem.

Since Windows "installs" apps by putting files all over the place, and changing things in the registry, file associations can be made easily. But, let's say I just downloaded MPlayer for Mac OS X (or whatever). I want all my movies to open in MPlayer. Then, I decide to move MPlayer's app bundle (hey, it's portable, right?). Will the association break? Or is that not how it's done at all on OS X?

How would one implement portable apps in Linux? Should it be similar to OS X's model? I know this is a very open-ended question, but any suggestions are appreciated.

OS X's Launch Services database keeps track of document bindings in several ways—generally it does its best to try to match an application even if you've moved it.

You can run lsregister -dump (lsregister is /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister) to see what the Launch Services database says about a binding. For example, if I bind text files to open with TextWrangler, I see:

handler id:            3124
    content type:  public.plain-text
    options:       
    all roles:     com.barebones.textwrangler (0x3ea30180)

public.plain-text is a Uniform Type Identifier (which maps to one or more file extensions, MIME types, etc., and may have subtypes) representing plain text, and com.barebones.textwrangler is the bundle ID of TextWrangler.

I'm not aware of any Linux standard as robust as this for document binding—to do something like the Mac, first there'd need to be a standard method for identifying applications regardless of their location or name (like the Java package-like/reverse-DNS method on the Mac), then a registry for type mappings and bindings that was followed by enough desktop environments to be useful, and some way of registering applications as they're installed.

You don't necessarily need separate files, like Info.plist in Mac application bundles, to store this information; even on Mac OS X you can embed information into a binary section which Launch Services indexes just fine (note that this is not a separate "fork" or extended attribute; it's like embedding debug information in an executable). So perhaps some derivative of the .desktop files could be embedded. On the other end, you'd need a way of recognizing content. Ideally you'd even be able to do content sniffing like the file(1) command to identify a document type; classic Mac OS did this with the Translation Manager (which permitted registration of converters from one format to another, as well as sniffers).

UTIs and the Translation Manager handle(d) clipboard and drag & drop content as well as files on disk; unifying these format representations is pretty useful while you're at it.

Each file browser (e.g. Nautilus, Konqueror) would have to be configured to use its own file associations. Fortunately, the Free Desktop project has been working on standardizing file associations (among many other things). According to the shared MIME database description, no formal specification has been written yet, but the format is pretty much standardized.

The Free Desktop project also uses .desktop files to provide "portability" (maybe you should use another word for this... perhaps "movable"?). If you move the executable outside of PATH, you can update the .desktop to point to the correct location.

Basically, there is a lot of ongoing work in the Linux community moving towards more user-friendly and developer-friendly (i.e. standardized) ways of accomplishing these goals. But things are not done yet.