XULRunner

XUL:Home Page XULRunner XUL:XUL Application Packaging XUL:Installation Story XUL:Xul Runner Licensing XUL:Lib XUL

XULRunner is a single installable package that can be used to bootstrap multiple XUL+XPCOM applications that are as rich as Firefox and Thunderbird.

The XULRunner Runtime

XULRunner should contain most of the common functionality expected by developers of rich internet applications. XULRunner will include:

• XPCOM
• Networking
• Gecko rendering engine
• core DOM editing and transaction support (no UI)
• Cryptography
• XUL language support, with its related XBL/RDF technologies and widgets useful for application development
• SVG (when ready)
• XSLT
• XML Extras
• Web Services
• Extension Manager
• Auto-update support
• typeahead-find toolbar
• history implementation
• accessibility support
• APIs and user interface for installing, uninstalling, and upgrading XUL applications. See the XUL:Installation Story.
• IPC services for communication between gecko-based apps
• RDF APIs
• docshell/window-targeting implementation (needs specification by bz!)

XULRunner will supply the following user interface elements, which may be overridden by embedders:

• File picker (will use native OS filepicker as appropriate)
• Find toolbar
• Helper app dialog/UI
• Security UI (maintenance of SSL keychains, etc)

XULRunner will not supply:

• Bookmarks
• More here!...

XULRunner might include:

• LDAP support
• Spellchecking support (with or without dictionaries provided) see bug 285977
• Core support for profile roaming (with application-specific extensibility)
• xforms (if not shipped by default, would be available as a core extension)

Also, 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. (See bug 285789).

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.

Technical Details

How do I build it?

Building XULRunner is a lot like building any other Mozilla application. Start by pulling client.mk from CVS:

$ cvs co mozilla/client.mk

Setup a mozconfig file. Here's what mine looks like:

$ cat $MOZCONFIG
export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

. $topsrcdir/xulrunner/config/mozconfig

If you want to build debug, then include these options:

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

If you are building on Linux, then you'll probably want to add these options as well:

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

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

Automating Builds

Current XULRunner build status

TODO

• Allocate and configure build system resources
  • win32: testing configuration on sweetlou
  • linux: ?
• Run automated builds
• Package results
• Publish to FTP site

What needs to be done?

XULRunner bugs

TODO: turn this into a bug list

• 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 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.
• DONE (except for xremote) XUL:Command_Line_Handling : better (generic) command-line handling APIs
• TODO -- Verify. Need to make sure Xremote and Win32 DDE works properly. By default, -remote should confine itself to talking to the same application type. See bug 280725.
• TODO 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.
  • WorldMaker: In Windows icons for (say) .xulapp could be handled via a simple shell extension. An ATL example
• TODO Need a fully app-independent toolkit. At the moment there are still a lot of places with #ifdef MOZ_PHOENIX or #if MOZ_THUNDERBIRD, which really hinders app development for other toolkit apps. There are also some files (see bug 250868, bug 250793 and bug 250867), which are essentially the same for all toolkit apps, but have to be carried in every app-package, making bug-fixing and maintenance a real nightmare.
• TODO Make it so that zero setup is required for app developers that want to play with XUL. (Suggestion from nrm).
• Make it possible to run xulrunner + app from read only media (CD's). Would be great for demoing webapps with webservice support etc.