Creating Applications with Mozilla

Appendix B. Development Tools

This book describes how to create applications using Mozilla. Generally, all parts that go into an application (including XUL, CSS, XBL, and DTD files) need to be built by hand since no complete ready-made development tools or development applications are available that would make these manual processes easier.

Creating all these files by hand is a great way to familiarize yourself with the way Mozilla works, and becoming more familiar with the inner workings of a Mozilla application certainly helps you see how the various parts fit together. Once you are comfortable creating these files by hand, using the platform becomes much easier and Mozilla fulfills its promise as a rich application development framework.

Development tools are important, though, and platforms like Mozilla can't obtain the sort of developer base they deserve until tools that make application creation easier are available. Although some people want to learn everything there is to know about creating applications with Mozilla, many simply want to create something without a lot of fuss.

Mozilla does not yet have a full set of development tools, but currently several development projects help with part of the application creation process. These tools don't make up a full-featured development environment, but they are useful. They also point the way to an area in Mozilla development that has a bright future and is worth watching.

This appendix describes some of the new tools -- including XULKit, Patch Maker, the DOM Inspector, the JavaScript Debugger, and MozillaTranslator -- that are already becoming a part of the regular repertoire of Mozilla developers. By learning about how to use these tools for your own project, you can radically simplify the application development process, especially when you combine these tools.

B.1. XULKit

Much of the manual editing described in Chapters Chapter 6, Chapter 7, and Chapter 8 can be automated with special scripts and templates being developed in the Mozilla source tree's tools/wizards section (these files are referred to collectively as the XULKit and can be found at http://www.hacksrus.com/~ginda/xulkit/doc/).

These tools help you develop your Mozilla application by generating as much of the basic content, structure, and packaging of an application as possible, leaving you free to work only on the aspects of your application that you care about. We mention XULKit first because it can make setting up new Mozilla applications a snap.

XULKit is essentially a set of two scripts: new-from-template.pl, which creates a new application framework, and makexpi.pl, which packages your application once you finish developing it.

B.1.1. new-from-template.pl Script

Though it's not named very elegantly, the new-from-template.pl Perl script takes information you provide in the form of a simple text file and uses it to create various parts of a Mozilla application. These parts include the XUL content, which has a basic menubar you can add to; an overlay that puts an item for your application into the Tools menu in the Mozilla browser; CSS for your XUL; and an installation script for the application package. You can base your application off of a couple of different templates, including a sophisticated one that lets you generate XPCOM interfaces for components you wish to use in your application, described below.

Using these scripts, you can add content and logic to your application, restyle it, or build your application however you would like. You can also register the resulting directory with the chrome registry to see it working in your local copy of Mozilla, and when you finish developing it, the application directory is already structured in exactly the way it must be to be checked into the Mozilla source tree's extensions directory (if you want to check it into this common location for applications that become a part of Mozilla). When you want to distribute your application as described in Chapter 6, you can use the other script in the XULKit, makexpi.pl, to package your application files into a cross-platform archive that can be installed from a regular web page.

To use the new-from-template.pl script, point it at a template that you filled out with your own information. It then generates the basic application code in the appropriate subdirectory structure:

new-from-template.pl      -t FILE [-o DIRECTORY] [-f[d]] [-h] [-?]

When you run the script, the XULKit creates a new top-level application directory. In this directory, the script creates the three main package directories, and it places some basic content in each one: a CSS file called mozreg.css in the skins subdirectory, a few XUL files in the content directory (including the overlay that defines a new menu item for the main browser that opens this new application), and localizable data in the mozref.dtd file in the locale subdirectory.

In addition to these files, the XULKit script creates contents.rdf files that describe each package, some Makefiles that instruct the Mozilla build process how to integrate this application into the build (which is a later step and not necessary to run the application), and an install.js file that executes the installation of this application when it appears in a XPI. (See Chapter 6 for more information about XPI, Mozilla's cross-platform installation file format.)

If you look at Example B-1 -- xul-app.tpl, which comes with the distribution of new-from-template.pl -- you can see how easy it is to fill out the basic information and create your own template.

Example B-1. Sample application template

# load default template for a XUL app
include "${top_wizard_dir}templates/xul-app.tpl"
# short app name (can not contain spaces.)
# until http://bugzilla.mozilla.org/show_bug.cgi?id=75670 is fixed, this needs
# to be all lowercase.
app_name_short=xulsample
# long app name (spaces are OK.)
app_name_long=Sample XUL Application (generated from sample.xul-app.tpl)
# name as it should appear in the menu
app_name_menu=Sample XUL App
# version to tell the .xpi installer
app_version=1.0

# author, used in various chrome and app registration calls
app_author=mozilla.org
# size of the package when installed, in kilobytes.
# this number is used by the install.js script to check for enough disk space
# before the .xpi is installed.  You can just guess for now, or put 1, and fix it
# in install.js before you make your .xpi file.
install_size_kilobytes=1

You can adapt the xul-app.tpl for your own purposes or use the sample.xul-app.tpl that is already filled out. Table B-1 details different options for new-from-template.pl.

Table B-1. Options for the new-from-template.pl script

Option	eDscription
-d	Recursively deletes the output directory before starting; requires the -f option.
-f	Forces file overwriting in the output directory.
-h	Displays a description of the specified template with -o. The template will not be processed. The template description is taken from the value of the template_description variable in the template file. template_descriptions provided by the main template file's template file(s) are not displayed.
-o DIRECTORY	Generates the template into the directory specified by DIRECTORY. If this directory already exists, new-from-template.pl will fail. This failure prevents you from accidentally overwriting an existing application. Use the -f option to continue anyway. Use -fd to force DIRECTORY to be deleted before the template is processed.
-t TEMPLATE	Processes the template specified by TEMPLATE. This file is usually in the my/ sub-directory, ending in .tpl.
-?	Shows usage information and exits.

B.1.1.1. XULKit templates

Two different application templates come with new-from-template.tpl, each with its own empty and sample versions. Example B-1 shows sample.xul-app.tpl in its entirety. The other template, xpcom-component.tpl, uses information you supply to create the framework for an XPCOM component. As with xul-app.tpl, the template comes with a sample that's already filled out.

This script creates an IDL file, a header file, and a stubbed-out CPP file in an application subdirectory structure you can use to begin coding your XPCOM component. In the xpcom-component.tpl, many variables do not need to be changed, but required fields are set aside in the template:

# variables the user's .tpl file MUST declare
required_variables = ${component_name}, ${implementation_guid}, \
                     ${interface_name}, ${interface_guid}

Using this script, you can fill out a subset of the template with the information XPCOM requires, and XPCOM will generate the basic files you need, as Example B-2 shows.

Example B-2. Sample XPCOM component template

# include default values
include "${top_wizard_dir}templates/xpcom-component.tpl"
component_name      = SampleComponent
implementation_guid = c6793b0c-1dd1-11b2-a246-92bf95c9d097
interface_name      = tstISampleComponent
interface_guid      = d03ea960-1dd1-11b2-9682-81ecad6a042a

B.1.2. makexpi.pl Script

In addition to the template-generating script described above, a second script takes your working application and creates an installable package, or XPI, out of it. This way, you can distribute it to others in the same way the various components of the Mozilla browser are distributed and installed when you use the Mozilla installer.

This script, makexpi.pl, takes an application directory as input and generates an XPI archive. It also manifests for various parts of your application, the installation script that goes inside this archive, and even the installation web page itself. While new-from-template.pl is designed to help you start your application, makexpi.pl takes your locally developed application and makes it into a package that can be distributed to other users and installed via the Web.

To use makexpi.pl, point it at a configuration file that you have edited to point at your application directory:

makexpi.pl      [-c <config-file>] [-d] [-r <revision>] [-?]

For example, to create a XPI out of your MyApp application directory, in which you created a file called MyApp.conf that defines the variables makexpi.pl needs, execute the script as follows:

perl makexpi.pl -c ~/appdev/MyApp/makexpi.conf -r 0.9.9

A makexpi.conf file defines the variables makexpi.pl needs to know about. Example B-3 shows an example of this file.

Example B-3. makexpi.conf file

# directory where xpi should be created
workdir     = /home/rginda/src/xulkit/sample-app/
# directory where jar.mn is
mndir       = ${workdir}/sampleapp/resources/
# location of templatized install.js file
installfile = ${xulkit_dir}/templates/xpi/install.js
# directory where mozilla's make-jars.pl and friends are
mozcfgdir   = ${xulkit_dir}/bin/
# name of resulting xpi file
xpifile = ${app_name_short}-${revision}.xpi

Table B-2 lists the options that are recognized by makexpi.pl.

Table B-2. Options for the makexpi.pl script

Options	Description
-c FILE	Specifies the configuration file to use.
-d	Doesn't remake the JAR, but packages the existing contents of the chrome/ directory as an XPI.
-r REVISION	Specifies the value of the ${revision} variable. This specification overrides any value specified in the configuration file and defaults to “0.01”. Typically, this number is used in the install.js script and as part of the XPI filename.
-?	Shows usage information and exits.

When you run the script against the configuration file, you end up with two separate pieces -- the XPI in which your application and its installation script are stored and a web page that you can post on a server to guide the XPI's installation. As described in Chapter 6, the web page interacts with the XPI's install.js to install and register your application in Mozilla. If you start your application with the new-from-template.pl script, then a template-processed version of install.js that works with your application is included as templates/xpi/install.js as part of the XULKit package.

B.1.3. Using XULKit

Given these two scripts and the templates that go with them, the XULKit encourages and makes the following application development workflow possible:

1. Fill out a new-from-template.pl template with your application information.
2. Run the new-from-template.pl script to generate the application directory.
3. Register your application in flat mode: as a directory in your local copy of Mozilla.
4. Develop your application: the XUL content, the CSS, the application code in JS, etc.
5. Test the application code.
6. Run makexpi.pl against your working application to create an installable package.
7. Put the XPI and the web page up on a server to create an install for your application.

That's it!

B.2. Patch Maker 2.0

Patch Maker is a free software program written by Gervase Markham that lets you change and improve Mozilla's user interface by using only a nightly build.

When you don't build the Mozilla source tree yourself, finding and getting to the files that need to be edited in Mozilla can be difficult. However, you can use the various Patch Maker commands in Build Mode to extract files from the right JARs, add them to your Patch Maker project, edit them, and create the patches, all in an integrated and easily traceable way. These patches can then be submitted back to mozilla.org so that developers working in the source tree can apply and test them. See the Section B.2.2 section later in this appendix for more information about using Patch Maker in this way.

This process is possible because Mozilla's user interface is written in XUL, JavaScript, and CSS, and interpreted at runtime. Because understanding CVS or compiling code isn't necessary, Patch Maker greatly lowers the barrier to entry for contributing code to Mozilla. Significant patches, such as one used for draggable toolbars, are made using this tool.

Patch Maker runs under Linux and Windows, and is experimental on Mac OS X. The latest version of Patch Maker is at http://www.gerv.net/software/patch-maker/. This application can be used in one of two modes. CVS mode is used by developers who develop and maintain code in a CVS tree and make their changes in the tree. Build mode makes it possible to produce patches that fix some bugs in Mozilla without downloading and compiling the source.

B.2.1. CVS Mode

In CVS mode, Patch Maker manages and tracks multiple patches to a bit of software. It uses unique tags (patch references such as bug numbers) to separate patches, knows what files are in each patch, and can perform operations on them. In CVS mode, Patch Maker can greatly speed up the process of creating, diffing, uploading, refreshing, and checking in a patch. CVS mode's basic commands for Patch Maker give you an idea of how developers working in the Mozilla source tree can use it to work more efficiently with patches and diffs. The basic CVS mode commands are described in Table B-3.

Table B-3. Patch Maker's CVS mode commands

Command	Description
pmlist	Shows the file list.
pmadd <filename>	Adds filename to the file list.
pmremove <filename>	Removes filename from the file list.
pmdiff	Does a cvs diff -u of all files in the file list. Extra arguments, such as -w, are passed through to diff. This command won't clobber your old diff if the new one has a size of zero.
pmview	Brings up your diff in an editor window.
pmupdate	Updates CVS on all files in the file list. Extra arguments to this command are passed through to the CVS update.
pmpatch	Patches your diff into your CVS tree. Takes a -R to back the patch out again.
pmedit <pattern>	Brings up files matching the pattern in your editor. The pattern is a glob, not a regexp. If there are no arguments supplied, then all files are opened.
pmwhich	Prints the current patch reference.
pmswitch <patchref>	Changes Patch Maker to work with a new patch reference. It automatically creates a pmupdate( ) and a pmpatch( ) (which won't have any effect if the patch is already applied.)
pmgrep <pattern>	Greps for pattern in all of the current patch's files. Good if you can't remember where you put some code.
pmcopy	Copies all files in the file list to their positions in your installed Mozilla tree. Takes a -f argument to force copying of all the files.
pmsetpath	Points Patch Maker to your current Mozilla-built installation's chrome directory. Use /usr/src/mozilla/dist/bin/chrome/ if you build yourself.
pmunjar	Unjars the chrome in your setpath installation.
pmexecute	Runs the executable in the setpath installation. Extra arguments to this command, such as &, are passed through to the executable.
pmcheckin	Runs pmwhich, pmupdate, pmdiff, and pmview to show what you are about to change, and then asks you if you really want to check in.
pmcvsadd	Does a CVS add of all files. Previously added files fail with a harmless message. You need to use this command for new files so the CVS diff will work properly.

See the CVS Mode instructions at the Patch Maker web site for instructions on how to use Patch Maker with your source tree.

B.2.2. Build Mode

The fact that Mozilla's user interface is interpreted at runtime rather than compile time makes it possible to change the interface and see your changes in the browser. In Build mode, Patch Maker can help you make these changes and apply, package, and send them to the developers who own the interface modules you edit. The Patch Maker's Build mode is a boon for Mozilla developers who do not build the CVS tree, but who want to take part in developing the interface, in the bug-fixing process, and in other aspects of Mozilla development.

In Mozilla-specific mode, which is triggered when you sit in a Mozilla build install point's chrome directory, you can make patches to Mozilla chrome without using a CVS tree. Patch Maker can cope with multiple patches and has a notion of the “current patch” -- the one you are working on at the moment. Patches are identified by a patch reference, or patchref, which is any combination of characters that make a legal filename on your platform. Bug numbers make very good patchrefs. You can add and remove files from Patch Maker's internal list of files that comprise the current patch.

B.2.2.1. Using Patch Maker in Build mode

Here are the steps to use Patch Maker in Build mode (flip the slashes in these paths if you are on Windows):

1. Set up Patch Maker (see the installation instructions at http://www.gerv.net/software/patch-maker/build-mode.html).
2. Change to the chrome directory of a Mozilla nightly build.
3. Execute pmuj to unjar your chrome.
4. Run Mozilla (../mozilla) to see if it still works. Turn off the XUL cache in the Debug > Networking preferences and quit Mozilla.
5. Execute pms test. Patch Maker will tell you that you are working on patch “test.”
6. Confirm this with pmw.
7. Execute pml. Note that no files are currently in your patch.
8. Execute pma content/navigator/navigator.xul to add navigator.xul to your patch.
9. Execute pml again and see if it was added. Experiment with pma and pmr if you like.
10. Execute pme. Notice that navigator.xul appears in your editor. Try pme foo to make sure you have no files that match “foo.”
11. Change navigator.xul -- e.g., search for “&mainWindow.title;” and replace that string with “MyBrowser.” Save this file.
12. Run Mozilla (../mozilla).
13. You should have a Mozilla titled “MyBrowser.”
14. Edit the file again to make it “YourBrowser.” Save the file.
15. Press Ctrl-N in your Mozilla window. The new window should be titled “YourBrowser.”
16. Execute pmd and pmv. You should now have an editor window with a unified diff showing the changes you made.
17. You could attach your patch to a Bugzilla bug by fishing the CVS version (test.diff) out of your Patch Maker data directory.

B.3. The DOM Inspector

The DOM Inspector tool, which is now installed by default in the Mozilla browser and accessible from Tools > Web Development, displays the document object mode of any document or part of the interface and allows you to update that DOM dynamically by changing attribute values, rearranging the structured content, or deleting nodes.

The DOM Inspector reads the DOM of the requested window or document into memory, where you can manipulate it. However, the DOM Inspector does not persist your changes back out to the file from which that DOM was originally loaded.

If you use JavaScript in the interface or to manipulate web pages, then you will recognize what a powerful tool it can be -- particularly given how hard it can be to see the interface's object model clearly and figure out which nodes in the DOM correspond to which parts of the displayed interface. The DOM Inspector also allows you to inspect local files and URLs.

To open a file for inspection in the DOM Inspector, choose either File > Inspect a Window or Inspect a URL . . . and enter the URL of the web document you want to inspect in the dialog. When the DOM Inspector loads a document, it displays the DOM (as shown in Figure B-1 of that document) as a tree structure on the lefthand side and the individual nodes with their attributes and other information on the righthand side.

Figure B-1. The DOM inspector interface

As you click on the nodes in the tree in the left panel, the DOM Inspector highlights the nodes that are part of the visible interface by pointing them out with a blinking red border. You can peck through the tree in the DOM Inspector and find all parts of the interface.

The DOM Inspector also displays any anonymous content that is part of the window. See Chapter 7 for information about anonymous content and the way it relates to the DOM. The anonymous content nodes that are bound to the window you specify become part of the DOM that the Inspector reads and can be analyzed and manipulated like any other node.

The pull-down widgets to the left of the pane headers let you select which portions of the DOM are displayed in the panels. By default, the DOM nodes are displayed, as shown in Figure B-1, but you can also display the associated stylesheets, the JavaScript objects, the XBL bindings, the document's box model, and other information.

B.4. The Component Viewer

The Component Viewer is a Mozilla application that displays all components and interfaces available to the XPCOM developer on the Mozilla platform. It is not installed by default in the Mozilla browser, like the DOM Inspector, but you can get binary installations that have it or you can build it from mozilla/extensios/cview if you use CVS.

Discovering components and interfaces is actually one of the trickier aspects of developing applications with Mozilla, so this tool can help you when you are at the initial stages of your application development and want to see which XPCOM components and interfaces are available. As shown in Figure B-2, the Component Viewer interface, like the DOM Inspector, has two main panels. The left side shows all components in Mozilla and the right side shows all interfaces.

Figure B-2. An interface displayed in the Component Viewer

In XPCOM, a single component can implement more than one interface. Thus, for example, the editor shell component (@mozilla.org/editor/editorshell;1) implements nsIURIContentListener, nsIEditorShell, nsIEditorSpellCheck, and others. If you open the interfaces, you will see the various methods those interfaces define. You can also right-click in the component viewer and access a context menu that lets you look up the selected item in LXR, which is the web-based source viewer for Mozilla.

B.5. Venkman: The JavaScript Debugger

Venkman is both a graphical and a console debugger. It is one of the most sophisticated examples of a Mozilla application and an indispensable tool for the many developing applications and web pages that rely on JavaScript. Like the DOM Inspector, you can access the JavaScript Debugger from the Tools > Web Development menu (if it was selected during the Mozilla install process). Figure B-3 shows Venkman in action.

Figure B-3. The JavaScript Debugger

Features such as breakpoint management, call stack inspection, and variable/object inspection are available from both the graphic interface and the console commands. The interactive console allows execution of arbitrary JavaScript code in the context of the target application and in the debugger's own context. Profiling measures the execution time of JavaScript functions during debugging, and pretty printing can re-indent and line wrap a poorly formatted function.

Keyboard shortcuts for the step commands are the same as in other common visual debugging environments, and console users should be familiar with Venkman's break, step, next, finish, frame, and where commands.

Venkman consists of eight main interface elements, referred to as “views.” These views display information such as local variables, source code, and the interactive console. They can be detached from the main window to save space on your desktop, or they can be hidden. The Venkman project page at http://www.mozilla.org/projects/venkman/ describes these views and their modes of operation.

Users can use a JavaScript API to add to the set of commands and views provided with Venkman. These add-ons can be shared among a project team or provided to the general public. The details of that API are not yet documented, but examples are found in Venkman itself. If you install Venkman, chrome://venkman/content/venkman-commands.js and chrome://venkman/content/venkman-views.js will contain Venkman's default commands and views.

The following sample session introduces you to the basic commands and use of the JavaScript Debugger. This sample session is based on the version of Venkman available at the time the book was written. To find out how to use the latest version of Venkman, read the Venkman walkthrough at http://www.mozilla.org/projects/venkman/venkman-walkthrough.html.

1. Invoke the -venkman command-line argument by typing mozilla -venkman to start Mozilla.

   You must start the debugger before the scripts it edits can be debugged. If you want to debug the file navigator.xul, for example, then Venkman must load before the main browser window. This limitation will either be fixed or worked around later. For the time being, you need to start the debugger first to debug browser chrome.

   Debugging JavaScript components is another example of when scripts must be loaded before the debugger is initialized. Because component registration occurs before command-line processing, when a component changes, it is reloaded at registration time and the debugger does not see it. Currently, the only way to work around it is to start the browser twice: once to re-register the modified component and once to debug it.

2. Launch a browser window and select “Navigator” from the debugger's Tasks menu.
3. Type break ContextMenu 357 in the debugger.

   The console command break is set and lists breakpoints. The first parameter is the filename that contains the JavaScript you want to break at. The second parameter is the line number. You don't need to specify the entire filename. In this example, we are setting a breakpoint in the function called when the browser wants to create a context menu for web content.

   Or, you could select nsContextMenu.js from the Scripts View, locate line 357, and click in the left margin. Setting breakpoints in this way is equivalent to using the break command in the console.

4. Type break in the debugger.

   If you don't provide arguments to the break command, all breakpoints are listed.

5. Create a context menu in the Navigator window.

   A right-click in the content area creates a context menu. You should have hit the breakpoint you just set. The debugger should have displayed “Stopped for breakpoint,” along with the filename, line number, and snippet source code where it stopped from.

6. Type step in the debugger.

   This command executes the line of JavaScript we're stopped on and stops again before the next line is executed. The step command is also available via the “Step Into” button on the toolbar and is bound to the F11 key.

   In addition to Step In, which executes a single line of JavaScript and stops, Step Over steps over a impending function call and returns control to the debugger when the call returns. Step Out executes until the current function call exits. At this point, you should be at line 359, this.onTextInput = this.isTargetATextBox(elem);.

7. Type props this in the debugger.

   The props command lists an object's properties. The letters and dashes before the values are the flags for that value. The flags are enumerated in Figure B-3, previously shown.

8. Step one more time.
9. You should be in the isTargetATextBox function call now.
10. Type frame in the debugger.

    When used without arguments, the frame command shows you the source code for the current frame (with a few lines of context).

11. Type scope in the debugger.

    The scope command lists the current frame's local variables. In this case, there are two locals: node and attrib. The node property is an argument to the function, while attrib is a local variable. The scope is also visible in the Stack View. Open the [isTargetATextBox] frame and the scope node below it.

12. Type where in the debugger.

    The where command lists the current call stack. The frame command can be used to change the current frame to any frame listed here. For example, to view variables in the code that called isTargetATextBox, type frame 1, and scope. To return to the top frame, type frame 0.

13. Type eval window._content.

    The eval command evaluates arbitrary JavaScript in the current frame. Running the eval command on window._content itself isn't very useful, so you'll have to think of something more creative.

14. Type break.

    The break command, when used without arguments, lists the current breakpoints by index.

15. Type clear 0.

    The clear command clears breakpoints. In this example, we clear by breakpoint number, which we got from the break command in the previous step.

16. Type cont.

    The cont command continues execution. The context menu should pop up as it always does.

B.6. MozillaTranslator

Chapter 11 provides information about how to make a Mozilla application usable in many different languages. Localizing an application can be simple if your application is small. For large applications, though, localizing can be a long and complicated process. Fortunately, interested and enthusiastic developers created a tool that makes this process easier.

MozillaTranslator is a program written in Java that reads in a package, provides an interface for changing the strings, and when finished, repackages the files for distribution. It is sophisticated enough to read JAR archives and output cross-platform installers (XPI). This type of solution is ideal for nontechnical people who translate the interface strings.

MozillaTranslator is more than just a program for inputting translated strings. The web site (http://www.MozillaTranslator.org/) has resources for setting up projects, uploading language packs, and finding the latest news on localization issues among other features.

To get to the point at which you can input your translated strings, you need to take some introductory steps. After downloading and installing MozillaTranslator, follow these steps:

1. Select File > Manage Products.
2. Press Add in the dialog to add a package.
3. In the window that comes up, give the project a label (for your own use) and point to the chrome\en-US.jar file within your Mozilla build (replace the path with your own Mozilla application locale path).
4. Exit the dialog.
5. Select File > Update Product.
6. Select Edit > Chrome View once the update has finished. You should see the component structure shown in Figure B-4. You can then choose fields in which to view the chrome view window.

Figure B-4. Chrome view in MozillaTranslator

At this point, you can edit the text straight from the chrome view. Another option is to bring up an edit window for a selected phrase, which supplies all possible editable fields in one window. An advanced search feature exists if you look for a piece of text in multiple files. When your strings are all done, packaging and preparing your language pack for distribution is as straightforward as selecting the Export > Jar File/XPI Install from the menus.

MozillaTranslator has the adaptability to handle any application locale, once you point it at the correct resources. Make sure that your files are packaged in the correct format -- namely, a JAR file. MozillaTranslator can handle all localizable resources: DTDs, string bundles, HTML, and RDF files.

B.7. Missing Parts

The tools highlighted so far are just some of the pieces needed to form a full-featured Mozilla development environment. Currently, several different areas of the application creation process would benefit greatly from a dedicated development tool. Some of the different types of needed tools are listed below.

B.7.1. Visual XUL Editors

XUL is a simple markup language that is similar to HTML. Some people prefer to create HTML code by hand, but others use programs that generate HTML code for them by using a simple point-and-click interface. The creation of a user-friendly XUL editing program would greatly simplify the creation of Mozilla applications and would allow many more people to start their own development projects.

So far, there have been at least a couple of attempts to create such a tool. A few projects, such as Vixen (http://www.mozilla.org/projects/vixen/) and XULMaker (http://xulmaker.mozdev.org), have started to create a visual XUL editor. So far, however, there isn't a tool that allows someone to quickly create a user interface without creating XUL and CSS code by hand.

B.7.2. Toolkits and Libraries

Mozilla applications currently have a lot of duplication due to a lack of standard libraries and toolkits. Different types of applications still need to do very similar things, so having common programming routines and interface widgets would greatly reduce the amount of time different developers spend recreating frequently needed parts of an application.

In this book, we discussed the JSLib project (http://jslib.mozdev.org), which is trying to create a repository of versatile functions that any Mozilla application can reuse. For a project like this to work, however, it needs to be widely available and accepted by the developer community. To ensure its wide availability, these common libraries and toolkits need to become a core part of the standard Mozilla development tools.

B.7.3. Integrating the Pieces

Popular development environments like Microsoft's Visual Studio bring together a cohesive set of tools; they provide the tool framework in which much of the setup, code generation, directory structure, linking, and other drudgery is handled automatically.

When used together, the tools described in this appendix can make your application development process easier. However, currently, all of these tools are located in different places and none of them interact with one another to provide a seamless development framework.

Even when all the tools do become available, it will be necessary to integrate each of these together to create a single development environment for Mozilla application builders. This single tool will allow you to create the shell of an application easily and fill it with XUL, CSS, JavaScript, and all other parts of a Mozilla application that can then be packaged easily when you are done.