XULRunner

These pages on wiki.mozilla.org are about XULRunner development and planning. If you want more information about developing or using XULRunner-based applications, visit the [[MDC:XULRunner Mozilla Developer Center], which includes documentation on building, running, and deploying XULRunner.

• XULRunner Roadmap

TODOs

A core requirement of XULRunner is the elimination of any app-specific #ifdef's. It does us no good if portions of the toolkit are #ifdef MOZ_PHOENIX or #ifdef MOZ_THUNDERBIRD. See bug 285789 and the Ifdef Manifesto.

The XUL Development Kit

In addition to the XULRunner runtime, the XULRunner build process will produce a Development Kit which contains tools for building XUL applications and extensions. As a first goal, these tools will provide:

• A build environment without all of the complexity of the Mozilla system for applications which consist entirely of XUL+JS (no binary components). This environment will produce extension XPIs and various kinds of xulapp installers.

• Web and XUL development tools that already have been developed, including DOM Inspector and Venkman JS Debugger

• A reference tool which will contain quick reference information for web and XUL development with links to the full reference information from developer.mozilla.org.

After you have built XULRunner, try running the sample XULRunner application:

$ cd dist/bin
$ ./xulrunner ../xpi-stage/simple/application.ini

Not much to see, I know. But, take a look at the contents of the apps/simple directory. Pretty simple (for a Mozilla-based app), wouldn't you say? Check out application.ini

User Profiles

An application running on top of the XULRunner has a fully "managed" profile directory for storing user specific data. XULRunner sets up the profile directory for applications automatically, and it uses the same profile locking mechanism used by existing applications like Firefox and Thunderbird.

The profile directory for an application is created under vendor/appname in the appropriate place on the user's system. For example, under Windows this would be:

$USERPROFILE\Application Data\$vendor\$appname\Profiles\$random.default

And under Unix systems it would be:

$HOME/.$vendor/$appname/Profiles/$random.default

Where $vendor and $appname are chosen by the XUL application, and $random is generated by XULRunner to obscure the location of the user's profile data.

The goal of this approach is to eliminate the need for the application developer to think about profile details. The default configuration should simply work without much fuss.

Down the road, we will want to allow XULRunner-based applications to participate in profile sharing. The goal here is to allow applications to share data that is common to the web platform such as SSL certificate, cookies, and the web cache. (See also: Mozilla2:Profile_Sharing.)

Versioning

XULRunner is a delivery vehicle for the XUL toolkit, which is not a frozen API. It is an API that has historically evolved over time, and it will likely continue to evolve for some time to come. While people agree that we need to stablize that API, it will not happen overnight.

For these reasons, it is important that XULRunner support applications that require specific versions of the toolkit. The current thinking is that XULRunner will be versioned (with version number matching the corresponding Gecko milestone), and applications will be able to specify the version(s) of the toolkit that they require.

This is in fact already implemented as options in the .xulapp file. Applications can specify a MinVersion and MaxVersion for the toolkit versions they require. XULRunner will refuse to load an application that does not pass the version test.

Some relatively old notes: XUL:Xul_Runner_Versioning

Buglist

• XULRunner bugs

• TODO -- Verify UA string. 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.
• TODO Need to support application icons. The best way to do this is have the app author provide a suite of PNGs in various sizes, and then convert these to the native OS format (.ico, .icns, .xbm) at app-install time. See bug 314651 and bug 314030
• WorldMaker: In Windows icons for (say) .xulapp could be handled via a simple shell extension. An ATL example

Make it possible to run xulrunner + app from read only media (CDs). Would be great for demoing webapps with webservice support etc. Needs investigation, probably something that needs extensive volunteer help.