Print
Creating Applications with Mozilla

The Future of Mozilla Application Development

by David Boswell and Brian King, coauthors of Creating Applications with Mozilla
06/27/2003

In April, mozilla.org announced a major update to its development roadmap. 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.

Stand-Alone Applications

The biggest news in the roadmap update is that mozilla.org 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 its Communicator browser suite, which included a web browser, a mail and news client, an HTML editor, and an address book. Over the past five years the community has rewritten 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 goal.

In place of the browser suite, development will focus on a stand-alone Mozilla Browser (based on the Mozilla Firebird project, formerly called "Project Phoenix") and a Mozilla Mail application (based on the Thunderbird 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.

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. MozillaZine recently ran a story on the future of one of the other applications from the browser suite, Composer, 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 Mozilla Amazon Browser or Xabyl, a visual XBL editor.

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 1.3.1 release 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 mozilla.org 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.

XPFE and the New Toolkit

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 mozilla.org 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.

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:

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.

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.

Related Reading

Creating Applications with Mozilla
By David Boswell, Brian King, Ian Oeschger, Pete Collins, Eric Murphy

The rest of this article provides details about how the xFly 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 conjunction 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.

The xFly example application has been taken from the Creating Applications with Mozilla 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.

Packaging Your Extension

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 Google toolbar or Optimoz. 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 Firebird 0.6 release (available for Windows, Linux, and Mac OS X) and the xFly extension. 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.

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.

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 install.js file, the full version of which can be found here. First of all the JAR file, xfly.jar, 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.

Pages: 1, 2

Next Pagearrow