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:
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.
Implications of this proposal on XULRunner
- 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 XULRunner. 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).