Application directories

This document details the application directory system, as used in the ROX desktop. Comments are welcome. Programmers writing programs which have nothing to do with the ROX Desktop are still encouraged to consider using this system.

Normally, Unix programs are installed by running a script (possibly inside a Makefile or RPM package) as root. This script scatters files over the filesystem (hopefully without breaking anything). If you're lucky, you may get the option of uninstalling afterwards. It might even work!

Installing programs with this scheme usually requires root access, or a lot of trouble. Sometimes both.

Application directories are self contained applications. The directory contains the program's help files, images, binaries and possibly other things. They may still depend on other libraries, though.

An application directory does not normally need an installer - you can just move it wherever you want. You can `uninstall' an application by deleting the directory. You can run an application directory by clicking on it.

First, I'd like to make a few points clear:

You do not need to change your PATH variable to use an application directory. To be found by the shell (which must be application-directory aware) it is only required that the application directory be in a PATH directory (eg '/usr/local/bin'), not that PATH point inside the application.
Normally, you can just click on an application to run it - no need to worry about PATH at all.
In a network environment, an application directory may contain multiple binaries (one for each platform) and will run the correct one when you click it.
Application directories may contain source code and will then automatically compile themselves when first run.
User choices are stored outside of the application directory. See the configuration system page for details.
Searching (for help) from the command-line is just as easy as searching /usr/doc - just search in 'Apps/*/Help'.
Application directories are not a new idea. They are already used by RISC OS, NextStep, MacOS and various other systems.
Application directories do not conflict with automatic dependancy handling systems such as RPM and apt. They do, however, allow much simpler, faster and more robust systems, such as Zero Install.

Wrappers

Wrappers are tiny application directories which just run an already-installed version of the program. This is useful when you have a lot of non-application-directory packaged software installed already.

See Peter Geer's Wrappers page and the ROX-Wrap project for details.

However, note that ROX-Filer now supports freedesktop.org .desktop files. You can often find these in /usr/share/applications or some similar location.

Re-packaging a program as an application directory

The simplest case is something like tgif where you just have an executable and a help file.
The steps would then be:

Create a directory called 'TGIF'
Move the executable inside as 'AppRun'
Put a PNG format icon inside as '.DirIcon'
Create a subdirectory called 'Help' and put the docs inside that
Optionally, create an AppInfo.xml file as explained in the filer's manual (this can be used to show a tooltip for the application, etc).

You should be able to run the application now by clicking on it, copy it to another machine by copying the directory, etc.
For something like Vim with resource files the steps are similar, but put the resources (vim-runtime) into a subdirectory and make the AppRun a shell script that sets the VIMRUNTIME environment variable and runs the binary, eg:

#!/bin/sh

APP_DIR=`dirname $0`
APP_DIR=`cd "$APP_DIR";pwd`

VIMRUNTIME="$APP_DIR/runtime"; export VIMRUNTIME
exec "$APP_DIR/Vim" "$@"

For applications which have the pathnames of their resources hard-coded you will need to edit the source code. This guide shows how:

Guide to Making Relocatable Applications (autopackage.org)

Library Directories

LibDirs are a special case of application directories. They are implemented the same but their use differs in two ways:

They are not normally run by the user (except perhaps to configure them), but are used by other programs.
They are not stored in the same place as application directories (~/Apps, /usr/local/apps, /usr/apps) but are stored in the same place as libraries (~/lib, /usr/local/lib, /usr/lib).

They are mainly used to provide libraries:

but can also used to provide other resources:

Links

D. J. Bernstein proposes something similar in slashpackage.

What about all my existing applications, as installed by RPM/DEB packages?

"Changing the current system to application directories seems like a big change. It also destroys much of the 'old' systems' advantages like automatic updates and dependancy handling, because the packaging systems don't know where you dropped your application directory."

Plain AppDirs do make automatic updates difficult. However, even if you get a package manager to place them in a central directory it's still worth-while keeping each download in its own directory. It prevents conflicts between packages and makes uninstall easier. This is what AddApp does, although this does mean that deleting a launcher doesn't remove the application (instead, you need a cache cleaner similar to APT's deborphan to work out what is no longer required).

"It seems like a great idea, but I'm sure some people have doubts (just as I do right now) as in how to integrate it with current systems. So: How can I integrate existing apps in /usr/bin etc. into Rox? Do I have to create links, or can I create menus, etc?" -- Jens Benecke

You can link executables in /usr/bin to your Apps directory or panel (or run them in place), but you'll have to add the icons manually. A better way is to use the .desktop files usually found in /usr/share/applications; that way they have an icon and a tooltip too.