File:  [mozdev] / books / www / articles / future.html
Revision 1.49: download - view: text, annotated - select for diffs - revision graph
Thu May 22 21:02:46 2003 UTC (16 years, 8 months ago) by david
Branches: MAIN
CVS tags: HEAD
updating article

<?php $title="The Future of Mozilla Application Development"; ?>

<h1>The Future of Mozilla Application Development</h1>

by <a href="">David Boswell</a> and <a
href="">Brian King</a>, coauthors of <a
href="">Creating Applications with

<p>In April, <a href=""></a> announced a
major update to their <a
href="">development roadmap</a>.  Some of
the changes in the new document represent a fundamental shift in the
direction and goals of the Mozilla community.  To help make sense of how
these changes will affect Mozilla application developers, this article
provides an analysis of the new roadmap and also demonstrates how to
convert an existing XPFE-based application into an application that uses
the new XUL toolkit. For the purposes of this article, the original
Mozilla applications will be referred to as the Mozilla suite, and the new
platform will be referred to as Mozilla Firebird.</p>

<h2>Stand-Alone Applications</h2>

<p>The biggest news in the roadmap update is that intends to
stop development of the application suite it currently produces in favor
of stand-alone applications.  When Netscape created the Mozilla open
source community, it released the code for their Communicator browser
suite that included a web browser, mail and news client, HTML editor and
an address book. Over the past five years the community has re-written the code 
base and has added many new features and other applications to the suite. 
The community itself has changed over this time and
producing a single monolithic set of applications is no longer its main

<p>In place of the browser suite, development will focus on a stand-alone
Mozilla Browser (based on the <a
href="">Mozilla Firebird</a>
project, formerly called project Phoenix) and a Mozilla Mail application
(based on the <a
project, formerly called project Minotaur). Both of these applications
represent a second generation of Mozilla application development. For a
short period, the first generation application suite will be worked on in
parallel with these new applications but development will switch focus to
Mozilla Browser and Mozilla Mail once it has been decided that the
transition to the new projects has been completed.</p>

<p>The fate of the other applications in the suite is a little less
certain.  Development will continue on each, but there are questions about
how they will be maintained and how they will be released once the browser
suite has been divided up.  <a
href="">MozillaZine</a> recently <a
href="">ran a
story</a> on the future of one of the other applications from the browser
suite, <a href="">Composer</a>, the HTML editing
tool. Daniel Glazman, a Netscape developer, has offered to maintain the
project going forward and to make it a stand-alone application so it can
be run separate from the browser.  Once that happens Composer will be just
like other independent Mozilla development projects such as the <a
Amazon Browser</a> or <a
href="">Xabyl</a>, a visual XBL

<p>For end-users it will probably take some time to get used to these
changes. Currently when a new version of Mozilla is released (for
instance, the <a href="">1.3.1
release</a> that came out on May 7) people who download it get a number of
distinct applications that are tightly integrated with one another.  In
the future, the different applications that releases will have
separate development schedules, will likely not be released at that same
time and will not be integrated as closely as before.  For users who think
Mozilla is currently bloated with too many features and want just a
browser, this is great news.  Of course there will still be a rich set of
extensions and add-ons for these applications that will allow you to
customize them however you like.</p>

<h2>XPFE and the New Toolkit</h2>

<p>Developers who have been using Mozilla as a platform for creating their
own XUL-based applications or add-ons will also have some changes to get
used to.  Although there will most likely be some pain in the transition,
the changes in the roadmap represent positive steps that
is taking to encourage Mozilla application development.  The new 
roadmap is a strong endorsement of the concept of XUL and of Mozilla 
application development in general.</p>

<p>There is a possibility for confusion when you take a closer look at
what exactly the roadmap is talking about changing.  In the transition
from Mozilla as an application suite to Mozilla as a platform for
application development, the specific XUL-based toolkit that has been in
use to date is being replaced with a new XUL-based toolkit taken from the
Phoenix project.  XUL itself is not being replaced though, just upgraded. 
The following quote from the roadmap clarifies this point:</p>

<blockquote>Note: the Phoenix toolkit is a compatible reimplementation of
the XPFE toolkit, with added features such as customizable toolbars. We
are not starting a new C++ GUI toolkit, we are simply moving to the next
generation XUL toolkit.</blockquote>

<p>Previously the application framework side of Mozilla was seen as
largely secondary to the original goal of creating an open source version
of the Communicator browser suite.  It's a testament to the developers in
the Mozilla community that they were able to create a high quality,
web-oriented, cross-platform application framework that a number of
companies and many individual developers are already using without that
having been their primary focus.  Now that Mozilla as platform is becoming
the new focus for the community, changes are inevitable but these should
all be changes that ultimately make life easier for developers.</p>

<p>The rest of this article provides details about how the <a
href="">xFly</a> application has been converted from
the old toolkit to the new one.  There is good news and there is bad news
about the work involved in the transition from a Mozilla package to a
Firebird extension.  The good news is that the basic architecture of the
application does not change -- XUL is still used in conjuction with other
technologies such as JavaScript, CSS and XBL.  The bad news is that there
are some changes to be aware of -- there are minimal changes in XUL and
XBL, but the biggest changes involve how things are packaged, registered
and launched.</p>

<p>The xFly example application has been taken from the <a
href="">Creating Applications with
Mozilla</a> book that deals with Mozilla development using the original
Mozilla browser suite.  Another purpose of this article was to examine how
relevant the book will remain when the new roadmap changes are fully in
place.  It is our opinion that other than the changes mentioned here, the
book will still be a very useful resource for application and extension
developers targeting the new Mozilla platform.</p>

<h2>Packaging Your Extension</h2>

A package in this context refers to software that was installed on top
of an existing Mozilla installation, and typically launched from that
environment. Examples include the <a
href="">Google toolbar</a> or 
<a href="">Optimoz</a>. As
already mentioned, the changes to your XUL and XBL code should be minimal
at the moment. However, the real fun begins when you want to register your
application and integrate it with the Firebird platform. This section will
cover the installation, the application settings, and the launch options
available to your extension once it is installed. 

To follow along with these examples, you will need to install the <a
0.6</a> release (available for Windows, Linux and Mac OS X) and the <a
href="">xFly extension</a>.  Once 
installed and launched you'll notice there's not much to the xFly 
application.  It is currently suffering from bit-rot, but it still serves 
as a useful example for our discussion here.

<i>Note: Keep in mind that the new roadmap just recently came out and
that many of the changes that it discusses have not been made yet. This
example should still give you a good idea about how you can go about
converting your existing application or extension, but be aware that
additional changes may come up as the toolkit continues to evolve.</i> 

Let's start at the end of the story, with the installation script, and
work back from there. xFly is packaged and distributed as a JAR file, 
contained beside an installation script in the XPInstall file.

    addFile("We're on our way ...", 
            "xfly.jar",           // jar source folder
            getFolder("chrome"),  // target folder
            "");                  // target subdir

    registerChrome(PACKAGE | DELAYED_CHROME, getFolder("chrome", "xfly.jar"), "content/");
    registerChrome(SKIN | DELAYED_CHROME, getFolder("chrome", "xfly.jar"), "skin/");
    registerChrome(LOCALE | DELAYED_CHROME, getFolder("chrome", "xfly.jar"), "locale/en-US/");

The code snippet above is taken from the <i>install.js</i> file, the full version of which 
<a href="">can 
be found here</a>. First of all the JAR file, <i>xfly.jar</i>, is added to 
the chrome folder, then the chrome folders contained within it are 
registered with the chrome registry. There is nothing new here, 
and therefore this script is backwards compatible with the Mozilla 
suite. This is important to remember, because if you have a will to do 
so, your extension will still work with the Mozilla suite as well as 
with Mozilla Firebird. Now let's examine some of the files contained 
in the chrome folders.

<h2>Registering with Mozilla Firebird</h2>

The first thing you will probably want is to add your application to 
the list of extensions in the Firebird Options (<i>Tools->Options</i> 
menu) window. All that is required for this is one line. In the extension 
manifest, the main <i>contents.rdf</i> file, add the following to 
the package description:


This tells Firebird to list the program in the list of extensions once 
it is registered. Here is the full description, which includes some other 
useful information such as the author, name, project URL, and a 
description of the extenstion which appears in the listing:

  <!-- package information -->
  <RDF:Description about="urn:mozilla:package:xfly"
        chrome:description="[2003-05-04] Adds xFly application for viewing examples contained in
        'Creating Applications with Mozilla' []"


<img src="" border=0 alt="xFly listed as a Firebird Extension">
<em>xFly listed as an extension in the Options window</em>

Another new description property is <code>chrome:settingsURL</code>. This 
enables the 'Settings' button which opens a window, the definition is which 
is contained in the file pointed to by the property. 
For most applications, the <i>contents.rdf</i> file resides in the 
<i>contents/</i> folder, or wherever you main XUL files are.

<h2>Launching Your Extension</h2>

There are many different ways that you can launch your application
from within Mozilla Firebird. These include via a menu item, or a toolbar
button.  It is the latter of these two that is discussed here. The
toolbars of Mozilla Firebird are highly customizable, much more so than in
the Mozilla suite. You can add and remove buttons which represent
application functionality via Drag&Drop, switch between text only/text and
images/images only, and add new toolbars. 

<img src="" border=0 alt="xFly D&D button">
<em>xFly D&D button on palette</em>

There are several steps you have to take to get this working. The first 
thing to do is to create your buttons. Note that to be effective you need 
to create 2 different size buttons, 20x20px and 32x32px. Firebird is 
capable of having small and large button icons. Next up is to write 
the XUL for the button:

  <toolbarpalette id="BrowserToolbarPalette">
    <toolbarbutton class="toolbarbutton-1" 
                   tooltiptext="&xflyButton.tooltip;" />

The <code>&lt;toolbarbutton&gt;</code> is contained in a <code>&lt;toolbarpalette&gt;</code>, 
the id of which (<b>BrowserToolbarPalette</b>) corresponds to the palette that contains the Drag&Drop 
buttons for the toolbar. The original XUL for this palette lives in the file 
<a href=""><i>browser.xul</i></a>, 
which is the main window for the Mozilla Firebird application

More modifications are needed to the main <i>contents.rdf</i> file, which as well as 
having the extension information, it contains the overlay information. More specifically, 
it contains information on chunks of XUL in files in your JAR file that you want to be 
added into some of the main Mozilla Firebird application files. So the following is added to 
the list of files to overlay:

&lt;RDF:li resource="chrome://browser/content/browser.xul"/&gt;

Then the list of files (in this case the <i>toolbarbutton</i> definition 
is contained in the file <i>xflyextensionsoverlay.xul</i>) is added to the sequence for this file. 
What is essentially being instructed is that this is the file that you will 
be overlaying (the file where the button will be going).

  <!-- Firebird -->
  <RDF:Seq about="chrome://browser/content/browser.xul">

If you 
<a href="">explore 
fully the mainifest file</a>, you will notice a 
description is still left in to overlay the Mozilla suite. A <i>menuitem</i> 
definition is contained in <i>xflymenuoverlay_moz.xul</i>, which overlays 
<a href=""><i>tasksOverlay.xul</i></a> -- 
the file that contains the original 'Tools' menu definition for Mozilla.
Once again this illustrates that your extension can be backwards compatible with the Mozilla suite.

Finally, you need to get the styles right for your button, related to the appearance of the image you created. 
Here is some of the code for the large and small buttons contained in the overlay CSS file, 
<a href=""><i>xflyextensionsoverlay.css</i></a>.

#xfly-button {
  list-style-image: url("chrome://xfly/skin/images/xflyButton32.png");
toolbar[iconsize="small"] #xfly-button {
  list-style-image: url("chrome://xfly/skin/images/xflyButton20.png");
You will fall at the last hurdle unless you register your stylesheet, similar to the registering of your overlay XUL file 
outlined previously, but this time in the 
<a href="">skin 
contents.rdf file</a>.

  <RDF:Seq about="urn:mozilla:stylesheets">
    <RDF:li resource="chrome://browser/content/browser.xul"/>
    <RDF:li resource="chrome://global/content/customizeToolbar.xul"/>

  <RDF:Seq about="chrome://global/content/customizeToolbar.xul">

  <RDF:Seq about="chrome://browser/content/browser.xul">

This convinces the two Firebird application XUL files to recognise the stylesheet that contains the image properties and values for 
your images. Something that we experienced during our testing was the icon not appearing correctly on the palette, 
instead as a group of unrelated icons. It was resolved by deleting your Mozilla Firebird user profile, something that is recommended 
in the <a href="">0.6 release notes</a>. 
Now everything should be in place, and you can grab your button and move onto one of your Firebird toolbars 
in the position that you wish.

<img src="" border=0 alt="xFly button on toolbar">
<em>xFly button on toolbar</em>

Hopefully this article has clarified some of the issues raised in the new
roadmap, and given you the information needed to create a new Mozilla
Firebird extension, or convert you Mozilla package to one. While the new
toolkit is by no means mature, the aspect concerning installation and
registering provides a standard mechanism for developers to distribute
their Mozilla applications and add-ons.  If you are interested in 
learning more, the following links should be a good place to start doing 
more research.

    <li>Releases Page<br/>
<a href=""></a>
    <li>Firebird Help, a comprehensive site with a lot of good information, including Themes, Extensions and Tips&Tricks<br/>
<a href=""></a>
    <li>Various projects at hosting Firebird Extensions:<br/>
<a href=""></a><br/>
<a href=""></a><br/>
<a href=""></a>


FreeBSD-CVSweb <>