XULRunner

XULRunner

Overview

The goal of the XULRunner application is to provide a lightweight container application that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird. See also libxul .

Profiles

An application running on top of the XULRunner should have a fully managed profile directory. ("Managed" meaning that each app built on top of XUL:Xul Runner should have its own vendor/appname directory for storing profile information.) An application developer should not have to think too hard about profile details! What about sharing profile data (f.e., installed certs between xulrunnerized firefox/tbird? Not an uncommon request.

What's in XULRunner?

XULRunner should basically be Firefox without everything under the browser/ directory. That means that it includes all the core "new" toolkit stuff that Firefox and Thunderbird currently share, including the extension manager. What is finally included in XULRunner is of course entirely up for debate ;-)

Where's development happening?

Development has now moved to the trunk. See bug 257162 for details. It is known to build under Linux (and Windows with some minor hacking in toolkit/mozapps/installer).

How do I build it?

Building XULRunner is a lot like building Firefox. Start by pulling the core files from CVS:

$ cvs co mozilla/client.mk mozilla/xulrunner/config

Here's what my .mozconfig file looks like:

$ cat $MOZCONFIG
. $topsrcdir/xulrunner/config/mozconfig

export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-freetype2

ac_add_options --enable-debug
ac_add_options --disable-optimize

ac_add_options --enable-xterm-updates

Ok, I built it. So, now what?

Try running the sample XULRunner application:

$ cd dist/bin
$ ./xulrunner apps/simple/simple.xulapp

What needs to be done?

• Need to improve the way we specify resources in the application directory. Currently, this is done with resource://app/path/to/some/file, but bsmedberg points out that it might be better to make resource:///path/to/some/file point into the application directory. This requires coming up with a new resource key to specify resources located in the XULRunner directory. "xre" or even "gre" come to mind. We settled on resource://app/ afterall.
• Need to write out chrome.rdf for chrome files located in the application directory. Currently, XULRunner looks for chrome/installed-chrome.txt in the application directory as well as in XULRunner's directory. bsmedberg suggests persisting the chrome registry in the profile directory instead of trying to manage multiple chrome.rdf files. We decided to use the chrome.rdf in the profile for chrome files under resource://app/chrome/.
• Need to make sure that there is a clear distinction between the application's {name, buildID, version} info and the corresponding info for XULRunner itself. For example, the UA string still needs to be generated properly.
• Static references to the application name may be an issue. For example, mozilla.in needs to know the vendor name and application name in order to locate the profile-relative init.d directory. These strings can't be statically defined anymore. Do we really care that much about init.d stuff? The init.d stuff is currently not supported.
• Need to allow applications to more easily override command line options. bsmedberg has some ideas on this subject at XUL:Command Line Handling.
• Need to make sure Xremote and Win32 DDE works properly. By default, -remote should confine itself to talking to the same application type.
• Need to support application icons. Ben Goodger has some ideas on this one. There are really two parts to this task: (1) under platforms that support it, it should be easy to associate an icon with the launcher for a XUL app, and (2) we should support window icons located outside the chrome/icons/default/ directory.
• Other stuff...

</body> </html>