<table style="float: right; border: 1px solid #999;"><tr><td>* 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 [[XULMDC:Home Page]XULRunner Mozilla Developer Center]{{XUL:XUL_Runner_TOC}}</table>, which includes documentation on building, running, and deploying 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 [http://developer.mozilla.org/en/docs/Roadmap|XULRunner Mozilla Developer CenterRoadmap]].
= XULRunner Overview = TODOs ==
XULRunner is a single "gecko runtime"installable package that can be used to bootstrap multiple XUL+XPCOMapplications that are as rich as Firefox and Thunderbird. It will provide mechanisms for installing, upgrading, and uninstalling these applications. XULRunner will also provide libXUL, an embedding framework which provides an embedding mechanism suitable for each platform. XULRunner is not an appropriate solution for small devices which cannot take the full memory or download weight of the XULRunner featureset. XULRunner must remain a relatively lightweight runtime. At the present time XULRunner applications are not expected to be forwards-compatible, and should be marked as compatible with a specific XULRunner version. A [http://benjamin.smedbergs.us/blog/2005-07-11/xulrunner-short-term-and-mid-term-roadmap/ tentative XULRunner roadmap] can be found on the weblog of lead developer [http://benjamin.smedbergs.us/ Benjamin Smedberg]. = 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!...* [[XForms]] (xforms will be available as an extension) XULRunner might include:* LDAP support* Spellchecking support (with or without dictionaries provided) see [https://bugzilla.mozilla.org/show_bug.cgi?id=285977 bug 285977]* Core support for profile roaming (with application-specific extensibility) Also, a core requirement of XULRunner is the elimination of any app-specific
<code>#ifdef</code>'s. It does us no good if portions of the toolkit are
<code>#ifdef MOZ_PHOENIX</code> or <code>#ifdef MOZ_THUNDERBIRD</code>. See [https://bugzilla.mozilla.org/show_bug.cgi?id=285789 bug 285789] and the [http://developer.mozilla.org/docs/When_To_Use_ifdefs 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 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 [http://www.mozilla.org/build/ building any other Mozilla application].
Start by pulling <code>client.mk</code> from CVS:
<pre>
$ cvs co mozilla/client.mk
</pre>
Setup a <code>mozconfig</code> file. Here's what mine looks like:
<pre>
$ cat $MOZCONFIG
export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
ac_add_options --enable-application=xulrunner
</pre>
If you want to build debug, then include these options:
<pre>
ac_add_options --enable-debug
ac_add_options --disable-optimize
</pre>
If you are building on Linux, then you'll probably want to add these
options as well:
<pre>
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-freetype2
</pre>
If you are building on Mac OS X 10.2, libxul will not link correctly. Use the --disable-libxul configure flag, or upgrade to Mac OS X 10.3. See [https://bugzilla.mozilla.org/show_bug.cgi?id=288370 Bug 288370] for further discussion.
XULRunner also builds [http://developer.mozilla.org/en/docs/Build_Documentation:Building_JavaXPCOM JavaXPCOM] by default, so you will need to install a JDK or else specify the --disable-javaconnect flag. The JAVA_HOME environment variable should be set to the location of your JDK.
After you have built XULRunner, try running the sample XULRunner application:
Not much to see, I know. But, take a look at the contents of the <code>apps/simple</code>
directory. Pretty simple (for a Mozilla-based app), wouldn't you say? Check out [http://lxr.mozilla.org/mozilla/source/xulrunner/examples/simple/application.ini application.ini]
== Pre-Built Binaries ==
Nightly Win32 and Linux builds can be found at [http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/ Mozilla's ftp server].
Unix/Linux builds can be found at [http://xulfr.org/download/XulRunner/ Xulfr.org]. There is also a shell script to automate builds directly from Mozilla's CVS.
== User Profiles ==
Some relatively old notes: [[XUL:Xul_Runner_Versioning]]
= Automating Builds =[http://tinderbox.mozilla.org/showbuilds.cgi?treeBuglist =XULRunner 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? =
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Toolkit&component=XULRunner&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= XULRunner bugs] TODO: turn this into a bug list
<ul>
<li>
<b>TODO</b>
Static references Need to the support application name may be an issueicons.For example, <code>mozilla.in</code> needs The best way to know do this is have the vendor name app author provide a suite of PNGs in various sizes, andapplication name in order then convert these to locate the profile-relative<code>initnative OS format (.d</code> directoryico, . These strings can't bestatically defined anymoreicns, . ''Do we really care that much about <code>initxbm) at app-install time.d</code>stuff? The init.d stuff is currently not supported.''See bug 314651 and bug 314030
<li> DONE (except for xremote)
[[XUL:Command_Line_Handling]] : better (generic) command-line handling APIs
<li>
<b>TODO -- Verify</b>.
Need to make sure Xremote and Win32 DDE works properly.
By default, <code>-remote</code> should confine itself to
talking to the same application type. See [https://bugzilla.mozilla.org/show_bug.cgi?id=280725 bug 280725].
<li>
<b>TODO</b>
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
<code>chrome/icons/default/</code> directory.
<ul>
<li>WorldMaker: In Windows icons for (say) .xulapp could be handled via a simple shell extension. [http://www.codeproject.com/shell/shellextguide9.asp An ATL example] </li>
</ul>
<li>
<b>TODO</b>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 [https://bugzilla.mozilla.org/show_bug.cgi?id=270235 hinders] app development for other toolkit apps. There are also some files (see bug [https://bugzilla.mozilla.org/show_bug.cgi?id=250793 250793]) 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. <li><b>TODO</b>Make it so that zero setup is required for app developers that want toplay with XUL. (Suggestion from nrm).</li> <li>Make it possible to run xulrunner + app from read only media (CDs). Would be great for demoing webapps with webservice support etc.</li>Needs investigation, probably something that needs extensive volunteer help.
</ul>
