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 Mozilla Developer Network, which includes documentation on building, running, and deploying XULRunner.

Contents

TODOs

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

The build system must be extended so that it is possible to build XULRunner in one objdir and applications in separate objdirs, propagating compiler feature tests from configure tests and keeping makefile configurations separate. See XULRunner:Build System Rework.

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 xpi-stage/simple
directory. Pretty simple (for a Mozilla-based app), wouldn't you say? (cough) Check out application.ini. See XUL Application Packaging for documentation on 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:

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.

Buglist

TODO -- Verify UA stringNeed 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.

TODONeed 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.