XUL:XUL Application Packaging

The following is a proposal for how to package XUL applications targeted at XUL Runner.

(Currently, there is no code in the tree that supports this, nor are there examples in the tree that demonstrates the proposal completely.)

Package Structure

At the top level, a XUL Application package is a directory with the extension 'xulapp' containing the following items:

application.ini - file - provides startup, configuration, and meta information for the application bundle chrome - directory - application chrome ( see [[1][Chrome Packaging]] ) defaults - directory - contains default preferences for the application

application.ini

More info coming...

Launching a XUL Application

A XUL application is launched simply by passing the application package to XulRunner as a parameter on startup. How this is done specifically depends on your operating system:

From the command line

Windows

xulrunner.exe path_to_package/myapplication.xulapp

Unix

xulrunner path_to_package/myapplication.xulapp

Mac OS X

open -a Xulrunner.app path_to_package/myapplication.xulapp

From the desktop UI

Windows

A shortcut is created by the application installation process that points to XULRunner with the application package as the command line parameter.

Unix

TBD

Mac OS X

The structure of a XUL application package is complient with Apple's requirements for document bundles:

http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/Concepts/DocumentBundles.html

Mac OS X recognizes the XUL application package as a document bundle handled by XULRunner. Double clicking on the application package launches XULRunner with the application package as a document to be opened.

Shipping Applications

How does one package and ship apps? We will use a zip file as the distributable. See XUL:Installation_Story for how this works with the install strategy for Windows users. On Mac or Unix, the "install" would consist of simply expanding the zip file automatically.

Proposal implcations for Xul Runner

• take folders, not ini files as the xulrunner file argument on startup

• Macs would tend to reuse the same process to load multiple applications - not the behavior desired for Xul Runnner. Rather than try to repackage chromes/extensions as executable bundles using a common lib (the GRE approach), we should have xulrunner act more as a launcher to effectively fork off a new process. (similar to how firefox behaves when loading new extensions on startup?)

Background information

Mac OS X factors that affect our strategy for application packaging and loading:

• Mac users expect drag-and-drop install of applications. The shipping "app" package must be ready to run after download and decompression. Also,

embedding installers in the download process (active-x/xul helpers) is rather difficult to infeasible in the mac world, and requiring installers only hinders the ease of packaging and installation of software for an already small target audience.

• Mac applications must be loaded by Launch Services. This happens by actions that evoke app loading such as double-clicking on the app in the finder,

double-clicking a document related to an app, or executing "open [app]" at the command line. If we want to pass a paramater to a properly launched app, we need to use a compatible way to do that (ODOC event posted to launched app).