Diff for /books/www/chapters/appb.html between versions 1.5 and 1.6

version 1.5, 2002/12/04 06:07:15 version 1.6, 2002/12/11 18:57:10
Line 1 Line 1
<HTML>    <style type="text/css">
<HEAD><TITLE>Appendix B</TITLE></HEAD><BODY BGCOLOR=WHITE><H2>Appendix B</H2>      div.c4 {text-align: center}
<H1><A NAME="77021"></A> Development Tools</H1>      div.c3 {font-weight: bold; text-align: center}
<P>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.    </style>
<P>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.
<P>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.    <h2>Appendix B</h2>
<P>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.    <h1><a name="77021"></a> Development Tools</h1>
<P>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.    <p>This book describes how to create applications using
<H2><A NAME="77022"></A> XULKit</H2>    Mozilla. Generally, all parts that go into an application
<P>Much of the manual  <!--INDEX STARTRANGE--XULKit development tools -->  <!--INDEX STARTRANGE--development:tools:XULKit --> editing described in     (including XUL, CSS, XBL, and DTD files) need to be built by
Chapters <A HREF="ch06.html#15291">6</A>, <A HREF="ch07.html#70326">7</A>, and <A HREF="ch08.html#78382">8</A> can be automated with special     hand since no complete ready-made development tools or
scripts and templates being developed in the Mozilla source tree's <I>tools/wizards</I> section (these files are referred to collectively as the XULKit and can be found at <I><A HREF="http://www.hacksrus.com/~ginda/xulkit/doc/">http://www.hacksrus.com/~ginda/xulkit/doc/</A></I>).    development applications are available that would make these
<P>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.    manual processes easier.</p>
<P>XULKit is essentially a set of two scripts: <I>new-from-template.pl</I>, which creates a new application framework, and <I>makexpi.pl</I>, which packages your application once you finish developing it.    <p>Creating all these files by hand is a great way to
<H3><A NAME="77023"></A> new-from-template.pl Script</H3>    familiarize yourself with the way Mozilla works, and becoming
<P>Though it's not named very elegantly, the <I> <!--INDEX new-from-template.pl Perl script (XULKit) -->  <!--INDEX scripts:new-from-template.pl --> new-from-template.pl</I> 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.    more familiar with the inner workings of a Mozilla application
<P>Using these scripts, you can add content and logic to your application, restyle it, or build your application however you would like. You can     certainly helps you see how the various parts fit together.
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 <A HREF="ch06.html#77063">Chapter 6</A>, you can use the other script in the XULKit, <I>makexpi.pl</I>, to package your application files into a cross-platform archive that can be installed from a regular web page.    Once you are comfortable creating these files by hand, using
<P>To use the <I>new-from-template.pl</I> 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:    the platform becomes much easier and Mozilla fulfills its
<PRE>new-from-template.pl      -t FILE [-o DIRECTORY] [-f[d]] [-h] [-?]</PRE>    promise as a rich application development framework.</p>
<P>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 <I>mozreg.css</I> in the <I>skins</I> subdirectory, a few XUL files in the <I>content</I> directory (including the overlay that defines a new menu item for the main browser that opens this new application), and localizable data in the <I>mozref.dtd</I> file in the <I>locale</I> subdirectory.    <p>Development tools are important, though, and platforms like
<P>In addition to these files, the XULKit script creates <I>contents.rdf</I> files that describe each package, some Makefiles that instruct the     Mozilla can't obtain the sort of developer base they deserve
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 <I>install.js</I> file that executes the installation of this application when it appears in a XPI. (See <A HREF="ch06.html#77063">Chapter 6</A> for more information about XPI, Mozilla's cross-platform installation file format.)    until tools that make application creation easier are
<P>If you look at Example B-1-<I>xul-app.tpl</I>, which comes with the distribution of <I>new-from-template.pl-</I>you can see how easy it is to fill out the basic information and create your own template.    available. Although some people want to learn everything there
    is to know about creating applications with Mozilla, many
<P><I>Example B-1: <A NAME="77016"></A></I>    simply want to create something without a lot of fuss.</p>
<I>Sample application template</I>    <p>Mozilla does not yet have a full set of development tools,
<PRE># load default template for a XUL app    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.</p>
     <p>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.</p>
     <h2><a name="77022"></a> XULKit</h2>
     <p>Much of the manual 
     <!--INDEX STARTRANGE==XULKit development tools --> 
     <!--INDEX STARTRANGE==development:tools:XULKit --> editing
     described in Chapters <a href="ch06.html#15291">6</a>, <a href=
     "ch07.html#70326">7</a>, and <a href="ch08.html#78382">8</a>
     can be automated with special scripts and templates being
     developed in the Mozilla source tree's <i>tools/wizards</i>
     section (these files are referred to collectively as the XULKit
     and can be found at <i><a href=
     "http://www.hacksrus.com/~ginda/xulkit/doc/">http://www.hacksrus.com/~ginda/xulkit/doc/</a></i>).</p>
     <p>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.</p>
     <p>XULKit is essentially a set of two scripts:
     <i>new-from-template.pl</i>, which creates a new application
     framework, and <i>makexpi.pl</i>, which packages your
     application once you finish developing it.</p>
     <h3><a name="77023"></a> new-from-template.pl Script</h3>
     <p>Though it's not named very elegantly, the <i>
     <!--INDEX new-from-template.pl Perl script (XULKit) --> 
     <!--INDEX scripts:new-from-template.pl -->
     new-from-template.pl</i> 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.</p>
     <p>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 <a href=
     "ch06.html#77063">Chapter 6</a>, you can use the other script
     in the XULKit, <i>makexpi.pl</i>, to package your application
     files into a cross-platform archive that can be installed from
     a regular web page.</p>
     <p>To use the <i>new-from-template.pl</i> 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:</p>
 <pre>
 new-from-template.pl      -t FILE [-o DIRECTORY] [-f[d]] [-h] [-?]
 </pre>
     <p>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 <i>mozreg.css</i> in the
     <i>skins</i> subdirectory, a few XUL files in the
     <i>content</i> directory (including the overlay that defines a
     new menu item for the main browser that opens this new
     application), and localizable data in the <i>mozref.dtd</i>
     file in the <i>locale</i> subdirectory.</p>
     <p>In addition to these files, the XULKit script creates
     <i>contents.rdf</i> 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
     <i>install.js</i> file that executes the installation of this
     application when it appears in a XPI. (See <a href=
     "ch06.html#77063">Chapter 6</a> for more information about XPI,
     Mozilla's cross-platform installation file format.)</p>
     <p>If you look at Example B-1-<i>xul-app.tpl</i>, which comes
     with the distribution of <i>new-from-template.pl-</i>you can
     see how easy it is to fill out the basic information and create
     your own template.</p>
     <p><i>Example B-1: <a name="77016"></a></i> <i>Sample
     application template</i></p>
 <pre>
 # load default template for a XUL app
 include "${top_wizard_dir}templates/xul-app.tpl"  include "${top_wizard_dir}templates/xul-app.tpl"
 # short app name (can not contain spaces.)  # short app name (can not contain spaces.)
# until <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=75670">http://bugzilla.mozilla.org/show_bug.cgi?id=75670</A> is fixed, this needs# until <a href=
 "http://bugzilla.mozilla.org/show_bug.cgi?id=75670">http://bugzilla.mozilla.org/show_bug.cgi?id=75670</a> is fixed, this needs
 # to be all lowercase.  # to be all lowercase.
 app_name_short=xulsample  app_name_short=xulsample
 # long app name (spaces are OK.)  # long app name (spaces are OK.)
Line 43  app_author=mozilla.org Line 138  app_author=mozilla.org
 # this number is used by the install.js script to check for enough disk space  # 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  # 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.  # in install.js before you make your .xpi file.
install_size_kilobytes=1</PRE>install_size_kilobytes=1
</pre>
<P>You can adapt the <I>xul-app.tpl</I> for your own purposes or use the <I>sample.xul-app.tpl</I> that is already filled out. Table B-1 details different options for <I>new-from-template.pl</I>.    <p>You can adapt the <i>xul-app.tpl</i> for your own purposes
    or use the <i>sample.xul-app.tpl</i> that is already filled
<P><I>Table B-1: <A NAME="77010"></A></I>    out. Table B-1 details different options for
<I>Options for the new-from-template.pl script</I>    <i>new-from-template.pl</i>.</p>
<P><TABLE WIDTH=100% BORDER=1><TR><TD><B>  Option</B></TD>      <TD><B>  Description</B></TD></TR>    <p><i>Table B-1: <a name="77010"></a></i> <i>Options for the
<TR><TD> -d</TD>        <TD>  Recursively deletes the output directory before starting; requires the </TD><TT>-f</TT> option.</TR>    new-from-template.pl script</i></p>
<TR><TD> -f</TD>        <TD>  Forces file overwriting in the output directory.</TD></TR>    <tt>-f</tt>option.<tt>-o</tt>. The template will not be
<TR><TD> -h</TD>        <TD>  Displays a description of the specified template with </TD><TT>-o</TT>. The template will not be processed. The template description is taken from the value of the <I>template_description</I> variable in the template file. template_description<TT>s</TT> provided by the main template file's template file(s) are not displayed.</TR>    processed. The template description is taken from the value of
<TR><TD> -o DIRECTORY</TD>      <TD>  Generates the template into the directory specified by </TD><TT>DIRECTORY</TT>. If this directory already exists, <I>new-from-template.pl</I> will fail. This failure prevents you from accidentally overwriting an existing application. Use the <TT>-f</TT> option to continue anyway. Use <TT>-fd</TT> to force <TT>DIRECTORY</TT> to be deleted before the template is processed.</TR>    the <i>template_description</i>variable in the template file.
<TR><TD> -t TEMPLATE</TD>     <TD>  Processes the template specified by </TD><TT>TEMPLATE</TT>. This file is usually in the <I>my/ sub-directory</I>, ending in <I>.tpl</I>.</TR>    template_description<tt>s</tt>provided by the main template
<TR><TD> -?</TD>     <TD>  Shows usage information and exits.</TD></TR></TABLE><P>    file's template file(s) are not displayed.<tt>DIRECTORY</tt>.
    If this directory already exists,
<H4><A NAME="77024"></A> XULKit templates</H4>    <i>new-from-template.pl</i>will fail. This failure prevents you
<P>Two different  <!--INDEX templates:XULKit tools --> application templates come with <I>new-from-template.tpl</I>, each with its own empty and sample versions. Example B-1 shows <I>sample.xul-app.tpl</I> in its entirety. The other template, <I>xpcom-component.tpl</I>, uses information you supply to create the framework for an XPCOM component. As with <I>xul-app.tpl</I>, the template comes with a sample that's already filled out.    from accidentally overwriting an existing application. Use the
<P>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 <I>xpcom-component.tpl</I>, many variables do not need to be changed, but required fields are set aside in the template:    <tt>-f</tt>option to continue anyway. Use <tt>-fd</tt>to force
<PRE># variables the user's .tpl file MUST declare    <tt>DIRECTORY</tt>to be deleted before the template is
     processed.<tt>TEMPLATE</tt>. This file is usually in the <i>my/
     sub-directory</i>, ending in <i>.tpl</i>.
     <table width="100%" border="1">
       <tr>
         <td><b>Option</b></td>
         <td><b>Description</b></td>
       </tr>
       <tr>
         <td>-d</td>
         <td>Recursively deletes the output directory before
         starting; requires the</td>
       </tr>
       <tr>
         <td>-f</td>
         <td>Forces file overwriting in the output directory.</td>
       </tr>
       <tr>
         <td>-h</td>
         <td>Displays a description of the specified template
         with</td>
       </tr>
       <tr>
         <td>-o DIRECTORY</td>
         <td>Generates the template into the directory specified
         by</td>
       </tr>
       <tr>
         <td>-t TEMPLATE</td>
         <td>Processes the template specified by</td>
       </tr>
       <tr>
         <td>-?</td>
         <td>Shows usage information and exits.</td>
       </tr>
     </table>
     <h4><a name="77024"></a> XULKit templates</h4>
     <p>Two different <!--INDEX templates:XULKit tools -->
     application templates come with <i>new-from-template.tpl</i>,
     each with its own empty and sample versions. Example B-1 shows
     <i>sample.xul-app.tpl</i> in its entirety. The other template,
     <i>xpcom-component.tpl</i>, uses information you supply to
     create the framework for an XPCOM component. As with
     <i>xul-app.tpl</i>, the template comes with a sample that's
     already filled out.</p>
     <p>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
     <i>xpcom-component.tpl</i>, many variables do not need to be
     changed, but required fields are set aside in the template:</p>
 <pre>
 # variables the user's .tpl file MUST declare
 required_variables = ${component_name}, ${implementation_guid}, \  required_variables = ${component_name}, ${implementation_guid}, \
${interface_name}, ${interface_guid}</PRE>${interface_name}, ${interface_guid}
<P>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.</pre>
    <p>Using this script, you can fill out a subset of the template
<P><I>Example B-2: <A NAME="77018"></A></I>    with the information XPCOM requires, and XPCOM will generate
<I>Sample XPCOM component template</I>    the basic files you need, as Example B-2 shows.</p>
<PRE> # include default values    <p><i>Example B-2: <a name="77018"></a></i> <i>Sample XPCOM
     component template</i></p>
 <pre>
  # include default values
  include "${top_wizard_dir}templates/xpcom-component.tpl"   include "${top_wizard_dir}templates/xpcom-component.tpl"
  component_name      = SampleComponent   component_name      = SampleComponent
  implementation_guid = c6793b0c-1dd1-11b2-a246-92bf95c9d097   implementation_guid = c6793b0c-1dd1-11b2-a246-92bf95c9d097
  interface_name      = tstISampleComponent   interface_name      = tstISampleComponent
 interface_guid      = d03ea960-1dd1-11b2-9682-81ecad6a042a</PRE> interface_guid      = d03ea960-1dd1-11b2-9682-81ecad6a042a
</pre>
<H3><A NAME="77025"></A> makexpi.pl Script</H3>    <h3><a name="77025"></a> makexpi.pl Script</h3>
<P>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.    <p>In addition to the template-generating script described
<P>This script, <I> <!--INDEX makexpi.pl Perl script (XULKit tools) -->  <!--INDEX scripts:makexpi.pl --> makexpi.pl</I>, 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 <I>new-from-template.pl</I> is designed to help you start your application, <I>makexpi.pl</I> takes your locally developed application and makes it into a package that can be distributed to other users and installed via the Web.    above, a second script takes your working application and
<P>To use <I>makexpi.pl</I>, point it at a configuration file that you have edited to point at your application directory:    creates an installable package, or XPI, out of it. This way,
<PRE>makexpi.pl      [-c &lt;config-file&gt;] [-d] [-r &lt;revision&gt;] [-?]</PRE>    you can distribute it to others in the same way the various
<P>For example, to create a XPI out of your <I>MyApp</I> application directory, in which you created a file called <I>MyApp.conf</I> that defines the variables<I> makexpi.pl</I> needs, execute the script as follows:    components of the Mozilla browser are distributed and installed
<PRE>perl makexpi.pl -c ~/appdev/MyApp/makexpi.conf -r 0.9.9</PRE>    when you use the Mozilla installer.</p>
<P>A <I>makexpi.conf</I> file defines the variables <I>makexpi.pl</I> needs to know about. Example B-3 shows an example of this file.    <p>This script, <i>
    <!--INDEX makexpi.pl Perl script (XULKit tools) --> 
<P><I>Example B-3: <A NAME="77020"></A></I>    <!--INDEX scripts:makexpi.pl --> makexpi.pl</i>, takes an
<I>makexpi.conf file</I>    application directory as input and generates an XPI archive. It
<PRE> # directory where xpi should be created    also manifests for various parts of your application, the
     installation script that goes inside this archive, and even the
     installation web page itself. While <i>new-from-template.pl</i>
     is designed to help you start your application,
     <i>makexpi.pl</i> takes your locally developed application and
     makes it into a package that can be distributed to other users
     and installed via the Web.</p>
     <p>To use <i>makexpi.pl</i>, point it at a configuration file
     that you have edited to point at your application
     directory:</p>
 <pre>
 makexpi.pl      [-c &lt;config-file&gt;] [-d] [-r &lt;revision&gt;] [-?]
 </pre>
     <p>For example, to create a XPI out of your <i>MyApp</i>
     application directory, in which you created a file called
     <i>MyApp.conf</i> that defines the variables <i>makexpi.pl</i>
     needs, execute the script as follows:</p>
 <pre>
 perl makexpi.pl -c ~/appdev/MyApp/makexpi.conf -r 0.9.9
 </pre>
     <p>A <i>makexpi.conf</i> file defines the variables
     <i>makexpi.pl</i> needs to know about. Example B-3 shows an
     example of this file.</p>
     <p><i>Example B-3: <a name="77020"></a></i> <i>makexpi.conf
     file</i></p>
 <pre>
  # directory where xpi should be created
  workdir     = /home/rginda/src/xulkit/sample-app/   workdir     = /home/rginda/src/xulkit/sample-app/
  # directory where jar.mn is   # directory where jar.mn is
  mndir       = ${workdir}/sampleapp/resources/   mndir       = ${workdir}/sampleapp/resources/
Line 94  ${interface_name}, ${interface_guid}</PR Line 269  ${interface_name}, ${interface_guid}</PR
  # directory where mozilla's make-jars.pl and friends are   # directory where mozilla's make-jars.pl and friends are
  mozcfgdir   = ${xulkit_dir}/bin/   mozcfgdir   = ${xulkit_dir}/bin/
  # name of resulting xpi file   # name of resulting xpi file
 xpifile = ${app_name_short}-${revision}.xpi</PRE> xpifile = ${app_name_short}-${revision}.xpi
</pre>
<P>Table B-2 lists the options that are recognized by <I>makexpi.pl</I>.    <p>Table B-2 lists the options that are recognized by
    <i>makexpi.pl</i>.</p>
<P><I>Table B-2: <A NAME="77012"></A></I>    <p><i>Table B-2: <a name="77012"></a></i> <i>Options for the
<I>Options for the makexpi.pl script</I>    makexpi.pl script</i></p>
<P><TABLE WIDTH=100% BORDER=1><TR><TD><B>  Options</B></TD>     <TD><B>  Description</B></TD></TR>    <i>chrome/</i>directory as an XPI.<i>${revision}</i>variable.
<TR><TD> -c FILE</TD>   <TD>  Specifies the configuration file to use.</TD></TR>    This specification overrides any value specified in the
<TR><TD> -d</TD>        <TD>  Doesn't remake the JAR, but packages the existing contents of the </TD><I>chrome/</I> directory as an XPI.</TR>    configuration file and defaults to ``0.01''. Typically, this
<TR><TD> -r REVISION</TD>       <TD>  Specifies the value of the </TD><I>${revision}</I> variable. This specification overrides any value specified in the configuration file and defaults to ``0.01''. Typically, this number is used in the <I>install.js</I> script and as part of the XPI filename.</TR>    number is used in the <i>install.js</i>script and as part of
<TR><TD> -?</TD>     <TD>  Shows usage information and exits.</TD></TR></TABLE><P>    the XPI filename.
    <table width="100%" border="1">
<P>When you run the script against the configuration file, you end up with two separate pieces-the XPI in which your application and its       <tr>
installation script are stored and a web page that you can post on a server to guide the XPI's installation. As described in <A HREF="ch06.html#77063">Chapter 6</A>, the web page interacts with the XPI's <I>install.js</I> to install and register your application in Mozilla. If you start your application with the <I>new-from-template.pl</I> script, then a template-processed version of <I>install.js</I> that works with your application is included as <I>templates/xpi/install.js</I> as part of the XULKit package.        <td><b>Options</b></td>
<H3><A NAME="77026"></A> Using XULKit</H3>        <td><b>Description</b></td>
<P>Given these two scripts and the templates that go with them, the XULKit encourages and makes the following application development workflow possible:      </tr>
<OL><P><LI>Fill out a <I>new-from-template.pl</I> template with your application information.<P>      <tr>
<P><LI>Run the <I>new-from-template.pl</I> script to generate the application directory.<P>        <td>-c FILE</td>
<P><LI>Register your application in flat mode: as a directory in your local copy of Mozilla.<P>        <td>Specifies the configuration file to use.</td>
<P><LI>Develop your application: the XUL content, the CSS, the application code in JS, etc.<P>      </tr>
<P><LI>Test the application code.<P>      <tr>
<P><LI>Run <I>makexpi.pl</I> against your working application to create an installable package.<P>        <td>-d</td>
<P><LI>Put the XPI and the web page up on a server to create an install for your application.<P></OL>        <td>Doesn't remake the JAR, but packages the existing
<P>That's <!--INDEX ENDRANGE--XULKit development tools -->  <!--INDEX ENDRANGE--development:tools:XULKit -->  it!        contents of the</td>
<H2><A NAME="77027"></A> Patch Maker 2.0</H2>      </tr>
<P>Patch Maker  <!--INDEX STARTRANGE--Patch Maker development tool -->  <!--INDEX STARTRANGE--development:tools: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.      <tr>
<P>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 <A HREF="#77029">"Build Mode</A>" section later in this appendix for more information about using Patch Maker in this way.        <td>-r REVISION</td>
<P>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.        <td>Specifies the value of the</td>
<P>Patch Maker runs under Linux and Windows, and is experimental on Mac OS X. The latest version of Patch Maker is at <I><A HREF="http://www.gerv.net/software/patch-maker/">http://www.gerv.net/software/patch-maker/</A></I>. 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.      </tr>
<H3><A NAME="77028"></A> CVS Mode</H3>      <tr>
<P>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.        <td>-?</td>
        <td>Shows usage information and exits.</td>
<P><I>Table B-3: <A NAME="77014"></A></I>      </tr>
<I>Patch Maker's CVS mode commands</I>    </table>
<P><TABLE WIDTH=100% BORDER=1><TR><TD><B>  Command</B></TD>     <TD><B>  Description</B></TD></TR>    <p>When you run the script against the configuration file, you
<TR><TD> pmlist</TD>    <TD>  Shows the file list.</TD></TR>    end up with two separate pieces-the XPI in which your
<TR><TD> pmadd &lt;filename</TD>&gt;   <TD>  Adds </TD><TT><I>filename</I></TT> to the file list.</TR>    application and its installation script are stored and a web
<TR><TD> pmremove &lt;filename</TD>&gt;    <TD>  Removes </TD><TT><I>filename</I></TT> from the file list.</TR>    page that you can post on a server to guide the XPI's
<TR><TD> pmdiff</TD>    <TD>  Does a cvs </TD><TT>diff -u</TT> of all files in the file list. Extra arguments, such as <TT>-w</TT>, are passed through to diff. This command won't clobber your old diff if the new one has a size of zero.</TR>    installation. As described in <a href="ch06.html#77063">Chapter
<TR><TD> pmview</TD>    <TD>  Brings up your diff in an editor window.</TD></TR>    6</a>, the web page interacts with the XPI's <i>install.js</i>
<TR><TD> pmupdate</TD>  <TD>  Updates CVS on all files in the file list. Extra arguments to this command are passed through to the CVS update.</TD></TR>    to install and register your application in Mozilla. If you
<TR><TD> pmpatch</TD>   <TD>  Patches your diff into your CVS tree. Takes a </TD><TT>-R</TT> to back the patch out again.</TR>    start your application with the <i>new-from-template.pl</i>
<TR><TD> pmedit &lt;pattern&gt;</TD>    <TD>  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.</TD></TR>    script, then a template-processed version of <i>install.js</i>
<TR><TD> pmwhich</TD>   <TD>  Prints the current patch reference.</TD></TR>    that works with your application is included as
<TR><TD> pmswitch &lt;patchref&gt;</TD> <TD>  Changes Patch Maker to work with a new patch reference. It automatically creates a </TD><TT>pmupdate( )</TT> and a <TT>pmpatch( )</TT> (which won't have any effect if the patch is already applied.)</TR>    <i>templates/xpi/install.js</i> as part of the XULKit
<TR><TD> pmgrep &lt;pattern&gt;</TD>    <TD>  Greps for </TD><TT><I>pattern</I></TT> in all of the current patch's files. Good if you can't remember where you put some code.</TR>    package.</p>
<TR><TD> pmcopy</TD>    <TD>  Copies all files in the file list to their positions in your installed Mozilla tree. Takes a </TD><TT>-f</TT> argument to force copying of all the files.</TR>    <h3><a name="77026"></a> Using XULKit</h3>
<TR><TD> pmsetpath</TD> <TD>  Points Patch Maker to your current Mozilla-built installation's </TD><I>chrome</I> directory. Use <I>/usr/src/mozilla/dist/bin/chrome/</I> if you build yourself.</TR>    <p>Given these two scripts and the templates that go with them,
<TR><TD> pmunjar</TD>   <TD>  Unjars the chrome in your setpath installation.</TD></TR>    the XULKit encourages and makes the following application
<TR><TD> pmexecute</TD> <TD>  Runs the executable in the setpath installation. Extra arguments to this command, such as </TD><TT>&amp;</TT>, are passed through to the executable.</TR>    development workflow possible:</p>
<TR><TD> pmcheckin</TD> <TD>  Runs </TD><TT>pmwhich</TT>, <TT>pmupdate</TT>, <TT>pmdiff</TT>, and <TT>pmview</TT> to show what you are about to change, and then asks you if you really want to check in.</TR>    <ol>
<TR><TD> pmcvsadd</TD>     <TD>  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.</TD></TR></TABLE><P>      <li>Fill out a <i>new-from-template.pl</i> template with your
      application information.</li>
<P>See the CVS Mode instructions at the Patch Maker web site for instructions on how to use Patch Maker with your source tree.      <li>Run the <i>new-from-template.pl</i> script to generate
<H3><A NAME="77029"></A> Build Mode</H3>      the application directory.</li>
<P>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.      <li>Register your application in flat mode: as a directory in
<P>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.      your local copy of Mozilla.</li>
<H4><A NAME="77030"></A> Using Patch Maker in Build mode</H4>      <li>Develop your application: the XUL content, the CSS, the
<P>Here are the steps to use Patch Maker in Build mode (flip the slashes in these paths if you are on Windows):      application code in JS, etc.</li>
<OL><P><LI>Set up Patch Maker (see the installation instructions at <I><A HREF="http://www.gerv.net/software/patch-maker/build-mode.html">http://www.gerv.net/software/patch-maker/build-mode.html</A></I>).<P>      <li>Test the application code.</li>
<P><LI>Change to the chrome directory of a Mozilla nightly build.<P>      <li>Run <i>makexpi.pl</i> against your working application to
<P><LI>Execute <TT>pmuj</TT> to unjar your chrome.<P>      create an installable package.</li>
<P><LI>Run Mozilla (../mozilla) to see if it still works. Turn off the XUL cache in the Debug &gt; Networking preferences and quit Mozilla.<P>      <li>Put the XPI and the web page up on a server to create an
<P><LI>Execute pms test. Patch Maker will tell you that you are working on patch "test."<P>      install for your application.</li>
<P><LI>Confirm this with pmw.<P>    </ol>
<P><LI>Execute pml. Note that no files are currently in your patch.<P>    <p>That's <!--INDEX ENDRANGE==XULKit development tools --> 
<P><LI>Execute pma content/navigator/navigator.xul to add <I>navigator.xul</I> to your patch.<P>    <!--INDEX ENDRANGE==development:tools:XULKit --> it!</p>
<P><LI>Execute <TT>pml</TT> again and see if it was added. Experiment with <TT>pma</TT> and <TT>pmr</TT> if you like.<P>    <h2><a name="77027"></a> Patch Maker 2.0</h2>
<P><LI>Execute <TT>pme</TT>. Notice that <I>navigator.xul</I> appears in your editor. Try <TT>pme</TT> <TT>foo</TT> to make sure you have no files that match "foo."<P>    <p>Patch Maker 
<P><LI>Change <I>navigator.xul-</I>e.g., search for "&amp;mainWindow.title;" and replace that string with "MyBrowser." Save this file.<P>    <!--INDEX STARTRANGE==Patch Maker development tool --> 
<P><LI>Run Mozilla (../mozilla).<P>    <!--INDEX STARTRANGE==development:tools:Patch Maker --> is a
<P><LI>You should have a Mozilla titled "MyBrowser."<P>    free software program written by Gervase Markham that lets you
<P><LI>Edit the file again to make it "YourBrowser." Save the file.<P>    change and improve Mozilla's user interface by using only a
<P><LI>Press Ctrl-N in your Mozilla window. The new window should be titled "YourBrowser."<P>    nightly build.</p>
<P><LI>Execute <TT>pmd</TT> and <TT>pmv</TT>. You should now have an editor window with a unified diff showing the changes you made.<P>    <p>When you don't build the Mozilla source tree yourself,
<P><LI>You could attach your patch to a Bugzilla bug by fishing the CVS version (<I>test.diff</I>) out of your Patch Maker data  <!--INDEX ENDRANGE--Patch Maker development tool -->  <!--INDEX ENDRANGE--development:tools:Patch Maker --> directory.<P></OL>    finding and getting to the files that need to be edited in
<H2><A NAME="77031"></A> The DOM Inspector</H2>    Mozilla can be difficult. However, you can use the various
<P>The DOM Inspector  <!--INDEX DOM Inspector development tool -->  <!--INDEX development:tools:DOM Inspector --> tool, which is now installed by default in the Mozilla browser and accessible from Tools &gt; 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.    Patch Maker commands in Build Mode to extract files from the
<BLOCKQUOTE><CENTER><B>NOTE</B></CENTER>    right JARs, add them to your Patch Maker project, edit them,
<P>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.<P></BLOCKQUOTE>    and create the patches, all in an integrated and easily
<P>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.    traceable way. These patches can then be submitted back to
<P>To open a file for inspection in the DOM Inspector, choose either File &gt; 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.    mozilla.org so that developers working in the source tree can
<P><CENTER><IMG SRC="foo.gif"></CENTER>    apply and test them. See the <a href="#77029">"Build Mode</a>"
<P><I>Figure B-1: <A NAME="77002"></A></I>    section later in this appendix for more information about using
<I>The DOM inspector interface</I>    Patch Maker in this way.</p>
    <p>This process is possible because Mozilla's user interface is
<P>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.    written in XUL, JavaScript, and CSS, and interpreted at
<P>The DOM Inspector also displays any anonymous content that is part of the window. See <A HREF="ch07.html#77027">Chapter 7</A> for information     runtime. Because understanding CVS or compiling code isn't
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.    necessary, Patch Maker greatly lowers the barrier to entry for
<P>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 Java-Script objects, the XBL bindings, the document's box model, and other information.    contributing code to Mozilla. Significant patches, such as one
<H2><A NAME="77032"></A> The Component Viewer</H2>    used for draggable toolbars, are made using this tool.</p>
<P>The  <!--INDEX Component Viewer development tool -->  <!--INDEX development:tools:Component Viewer --> 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 <I>mozilla/extensios/cview</I> if you use CVS.    <p>Patch Maker runs under Linux and Windows, and is
<P>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.    experimental on Mac OS X. The latest version of Patch Maker is
<P><CENTER><IMG SRC="foo.gif"></CENTER>    at <i><a href=
<P><I>Figure B-2: <A NAME="77004"></A></I>    "http://www.gerv.net/software/patch-maker/">http://www.gerv.net/software/patch-maker/</a></i>.
<I>An interface displayed in the Component Viewer</I>    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
<P>In XPCOM, a single component can implement more than one interface. Thus, for example, the editor shell component (<I>@mozilla.org/editor/editorshell;1</I>) implements <I>nsIURIContentListener</I>, <I>nsIEditorShell</I>, <I>nsIEditorSpellCheck</I>, 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.    and make their changes in the tree. Build mode makes it
<H2><A NAME="77033"></A> Venkman: The JavaScript Debugger</H2>    possible to produce patches that fix some bugs in Mozilla
<P>Venkman is  <!--INDEX STARTRANGE--Venkman development tool -->  <!--INDEX STARTRANGE--development:tools:Venkman --> 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 &gt; Web Development menu (if it was selected during the Mozilla install process). Figure B-3 shows Venkman in action.    without downloading and compiling the source.</p>
<P><CENTER><IMG SRC="foo.gif"></CENTER>    <h3><a name="77028"></a> CVS Mode</h3>
<P><I>Figure B-3: <A NAME="77006"></A></I>    <p>In CVS mode, Patch Maker manages and tracks multiple patches
<I>The JavaScript Debugger</I>    to a bit of software. It uses unique tags (patch references
    such as bug numbers) to separate patches, knows what files are
<P>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.    in each patch, and can perform operations on them. In CVS mode,
<P>Keyboard shortcuts for the <TT>step</TT> commands are the same as in other common visual debugging environments, and console users should be familiar with Venkman's <TT>break</TT>, <TT>step</TT>, <TT>next</TT>, <TT>finish</TT>, <TT>frame</TT>, and <TT>where</TT> commands.    Patch Maker can greatly speed up the process of creating,
<P>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 <I><A HREF="http://www.mozilla.org/projects/venkman/">http://www.mozilla.org/projects/venkman/</A></I> describes these views and their modes of operation.    diffing, uploading, refreshing, and checking in a patch. CVS
<P>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, <I>chrome://venkman/content/venkman-commands.js</I> and <I>chrome://venkman/content/venkman-views.js</I> will contain Venkman's default commands and views.    mode's basic commands for Patch Maker give you an idea of how
<P>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 <I><A HREF="http://www.mozilla.org/projects/venkman/venkman-walkthrough.html">http://www.mozilla.org/projects/venkman/venkman-walkthrough.html</A></I>.    developers working in the Mozilla source tree can use it to
<OL><P><LI>Invoke the <TT>-venkman</TT> command-line argument by typing mozilla -venkman to start Mozilla.<P>    work more efficiently with patches and diffs. The basic CVS
<P>You must start the debugger before the scripts it edits can be debugged. If you want to debug the file <I>navigator.xul</I>, 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.<P>    mode commands are described in Table B-3.</p>
<P>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.<P>    <p><i>Table B-3: <a name="77014"></a></i> <i>Patch Maker's CVS
<P><LI>Launch a browser window and select "Navigator" from the debugger's Tasks menu.<P>    mode commands</i></p>
<P><LI>Type break ContextMenu 357 in the debugger.<P>    &gt; <tt><i>filename</i></tt>to the file list.&gt;
<P>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.<P>    <tt><i>filename</i></tt>from the file list.<tt>diff -u</tt>of
<P>Or, you could select <I>nsContextMenu.js</I> from the Scripts View, locate line 357, and click in the left margin. Setting breakpoints in this way is equivalent to using the <TT>break</TT> command in the console.<P>    all files in the file list. Extra arguments, such as
<P><LI>Type break in the debugger.<P>    <tt>-w</tt>, are passed through to diff. This command won't
<P>If you don't provide arguments to the <TT>break</TT> command, all breakpoints are listed.<P>    clobber your old diff if the new one has a size of
<P><LI>Create a context menu in the Navigator window.<P>    zero.<tt>-R</tt>to back the patch out again.<tt>pmupdate(
<P>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.<P>    )</tt>and a <tt>pmpatch( )</tt>(which won't have any effect if
<P><LI>Type step in the debugger.<P>    the patch is already applied.)<tt><i>pattern</i></tt>in all of
<P>This command executes the line of JavaScript we're stopped on and stops again before the next line is executed. The <TT>step</TT> command is also available via the "Step Into" button on the toolbar and is bound to the F11 key.<P>    the current patch's files. Good if you can't remember where you
<P>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, <TT>this.onTextInput</TT> <TT>=</TT> <TT>this.isTargetATextBox(elem);</TT>.<P>    put some code.<tt>-f</tt>argument to force copying of all the
<P><LI>Type props this in the debugger.<P>    files.<i>chrome</i>directory. Use
<P>The <TT>props</TT> command lists an object's properties. The letters and dashes before the values are the flags for that value. The flags are enumerated in <A HREF="#77006">Figure B-3</A>, previously shown.<P>    <i>/usr/src/mozilla/dist/bin/chrome/</i>if you build
<P><LI>Step one more time.<P>    yourself.<tt>&amp;</tt>, are passed through to the
<P><LI>You should be in the <TT>isTargetATextBox</TT> function call now.<P>    executable.<tt>pmwhich</tt>, <tt>pmupdate</tt>,
<P><LI>Type frame in the debugger.<P>    <tt>pmdiff</tt>, and <tt>pmview</tt>to show what you are about
<P>When used without arguments, the <TT>frame</TT> command shows you the source code for the current frame (with a few lines of context).<P>    to change, and then asks you if you really want to check in.
<P><LI>Type scope in the debugger.<P>    <table width="100%" border="1">
<P>The <TT>scope</TT> 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.<P>      <tr>
<P><LI>Type where in the debugger.<P>        <td><b>Command</b></td>
<P>The <TT>where</TT> command lists the current call stack. The <TT>frame</TT> command can be used to change the current frame to any frame listed here. For example, to view variables in the code that called <TT>isTargetATextBox</TT>, type frame 1, and scope. To return to the top frame, type frame 0.<P>        <td><b>Description</b></td>
<P><LI>Type eval window._content.<P>      </tr>
<P>The <TT>eval</TT> command evaluates arbitrary JavaScript in the current frame. Running the <TT>eval</TT> command on <TT>window._content</TT> itself isn't very useful, so you'll have to think of something more creative.<P>      <tr>
<P><LI>Type break.<P>        <td>pmlist</td>
<P>The <TT>break</TT> command, when used without arguments, lists the current breakpoints by index.<P>        <td>Shows the file list.</td>
<P><LI>Type clear 0.<P>      </tr>
<P>The <TT>clear</TT> command clears breakpoints. In this example, we clear by breakpoint number, which we got from the <TT>break</TT> command in the previous step.<P>      <tr>
<P><LI>Type cont.<P>        <td>pmadd &lt;filename</td>
<P>The <TT>cont</TT> command continues execution. The context menu should pop up as it always  <!--INDEX ENDRANGE--Venkman development tool -->  <!--INDEX ENDRANGE--development:tools:Venkman --> does.<P></OL>        <td>Adds</td>
<H2><A NAME="77034"></A> MozillaTranslator</H2>      </tr>
<P><A HREF="ch11.html#77028">Chapter 11</A> provides <!--INDEX MozillaTranslator development tool -->  <!--INDEX       <tr>
development:tools:MozillaTranslator -->  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.        <td>pmremove &lt;filename</td>
<P>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.        <td>Removes</td>
<BLOCKQUOTE><CENTER><B>NOTE</B></CENTER>      </tr>
<P>MozillaTranslator is more than just a program for inputting translated strings. The web site (<I><A HREF="http://www.MozillaTranslator.org/">http://www.MozillaTranslator.org/</A></I>) has resources for setting up projects, uploading language packs, and finding the latest news on localization issues among other features.<P></BLOCKQUOTE>      <tr>
<P>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:        <td>pmdiff</td>
<OL><P><LI>Select File &gt; Manage Products.<P>        <td>Does a cvs</td>
<P><LI>Press Add in the dialog to add a package.<P>      </tr>
<P><LI>In the window that comes up, give the project a label (for your own use) and point to the <I>chrome\en-US.jar</I> file within your Mozilla build (replace the path with your own Mozilla application locale path).<P>      <tr>
<P><LI>Exit the dialog.<P>        <td>pmview</td>
<P><LI>Select File &gt; Update Product.<P>        <td>Brings up your diff in an editor window.</td>
<P><LI>Select Edit &gt; 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.<P></OL>      </tr>
<P><CENTER><IMG SRC="foo.gif"></CENTER>      <tr>
<P><I>Figure B-4: <A NAME="77008"></A></I>        <td>pmupdate</td>
<I>Chrome view in MozillaTranslator</I>        <td>Updates CVS on all files in the file list. Extra
        arguments to this command are passed through to the CVS
<P>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 &gt; Jar File/XPI Install from the menus.        update.</td>
<P><!--INDEX localization:tools --> 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.      </tr>
<H2><A NAME="77035"></A> Missing Parts</H2>      <tr>
<P>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.        <td>pmpatch</td>
<H3><A NAME="77036"></A> Visual XUL Editors</H3>        <td>Patches your diff into your CVS tree. Takes a</td>
<P>XUL is a simple  <!--INDEX visual editors (development tools) -->  <!--INDEX development:tools:visual editors --> 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.      </tr>
<P>So far, there have been at least a couple of attempts to create such a tool. A few projects, such as Vixen (<I><A HREF="http://www.mozilla.org/projects/vixen/">http://www.mozilla.org/projects/vixen/</A></I>) and XULMaker (<I><A HREF="http://xulmaker.mozdev.org">http://xulmaker.mozdev.org</A></I>), 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.      <tr>
<H3><A NAME="77037"></A> Toolkits and Libraries</H3>        <td>pmedit &lt;pattern&gt;</td>
<P>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.        <td>Brings up files matching the pattern in your editor.
<P>In this book, we discussed the JSLib project (<I><A HREF="http://jslib.mozdev.org">http://jslib.mozdev.org</A></I>), 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.        The pattern is a glob, not a regexp. If there are no
<H3><A NAME="77038"></A> Integrating the Pieces</H3>        arguments supplied, then all files are opened.</td>
<P>Popular development  <!--INDEX development:tools:integration --> 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.      </tr>
<P>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.      <tr>
<P>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, Java-Script, and all other parts of a Mozilla application that can then be packaged easily when you are done.        <td>pmwhich</td>
<HR>        <td>Prints the current patch reference.</td>
<!-- ?php require(NOTES); ? -->      </tr>
<?php $post_to_list=NO; require(ANNOTATE); ?>      <tr>
</BODY>        <td>pmswitch &lt;patchref&gt;</td>
</HTML>        <td>Changes Patch Maker to work with a new patch reference.
         It automatically creates a</td>
       </tr>
       <tr>
         <td>pmgrep &lt;pattern&gt;</td>
         <td>Greps for</td>
       </tr>
       <tr>
         <td>pmcopy</td>
         <td>Copies all files in the file list to their positions in
         your installed Mozilla tree. Takes a</td>
       </tr>
       <tr>
         <td>pmsetpath</td>
         <td>Points Patch Maker to your current Mozilla-built
         installation's</td>
       </tr>
       <tr>
         <td>pmunjar</td>
         <td>Unjars the chrome in your setpath installation.</td>
       </tr>
       <tr>
         <td>pmexecute</td>
         <td>Runs the executable in the setpath installation. Extra
         arguments to this command, such as</td>
       </tr>
       <tr>
         <td>pmcheckin</td>
         <td>Runs</td>
       </tr>
       <tr>
         <td>pmcvsadd</td>
         <td>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.</td>
       </tr>
     </table>
     <p>See the CVS Mode instructions at the Patch Maker web site
     for instructions on how to use Patch Maker with your source
     tree.</p>
     <h3><a name="77029"></a> Build Mode</h3>
     <p>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.</p>
     <p>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.</p>
     <h4><a name="77030"></a> Using Patch Maker in Build mode</h4>
     <p>Here are the steps to use Patch Maker in Build mode (flip
     the slashes in these paths if you are on Windows):</p>
     <ol>
       <li>Set up Patch Maker (see the installation instructions at
       <i><a href=
       "http://www.gerv.net/software/patch-maker/build-mode.html">http://www.gerv.net/software/patch-maker/build-mode.html</a></i>).</li>
       <li>Change to the chrome directory of a Mozilla nightly
       build.</li>
       <li>Execute <tt>pmuj</tt> to unjar your chrome.</li>
       <li>Run Mozilla (../mozilla) to see if it still works. Turn
       off the XUL cache in the Debug &gt; Networking preferences
       and quit Mozilla.</li>
       <li>Execute pms test. Patch Maker will tell you that you are
       working on patch "test."</li>
       <li>Confirm this with pmw.</li>
       <li>Execute pml. Note that no files are currently in your
       patch.</li>
       <li>Execute pma content/navigator/navigator.xul to add
       <i>navigator.xul</i> to your patch.</li>
       <li>Execute <tt>pml</tt> again and see if it was added.
       Experiment with <tt>pma</tt> and <tt>pmr</tt> if you
       like.</li>
       <li>Execute <tt>pme</tt>. Notice that <i>navigator.xul</i>
       appears in your editor. Try <tt>pme</tt> <tt>foo</tt> to make
       sure you have no files that match "foo."</li>
       <li>Change <i>navigator.xul-</i>e.g., search for
       "&amp;mainWindow.title;" and replace that string with
       "MyBrowser." Save this file.</li>
       <li>Run Mozilla (../mozilla).</li>
       <li>You should have a Mozilla titled "MyBrowser."</li>
       <li>Edit the file again to make it "YourBrowser." Save the
       file.</li>
       <li>Press Ctrl-N in your Mozilla window. The new window
       should be titled "YourBrowser."</li>
       <li>Execute <tt>pmd</tt> and <tt>pmv</tt>. You should now
       have an editor window with a unified diff showing the changes
       you made.</li>
       <li>You could attach your patch to a Bugzilla bug by fishing
       the CVS version (<i>test.diff</i>) out of your Patch Maker
       data <!--INDEX ENDRANGE==Patch Maker development tool --> 
       <!--INDEX ENDRANGE==development:tools:Patch Maker -->
       directory.</li>
     </ol>
     <h2><a name="77031"></a> The DOM Inspector</h2>
     <p>The DOM Inspector 
     <!--INDEX DOM Inspector development tool --> 
     <!--INDEX development:tools:DOM Inspector --> tool, which is
     now installed by default in the Mozilla browser and accessible
     from Tools &gt; 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.</p>
     <blockquote>
       <div class="c3">
         NOTE
       </div>
       <p>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.</p>
     </blockquote>
     <p>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.</p>
     <p>To open a file for inspection in the DOM Inspector, choose
     either File &gt; 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.</p>
     <div class="c4">
       <img src="foo.gif">
     </div>
     <p><i>Figure B-1: <a name="77002"></a></i> <i>The DOM inspector
     interface</i></p>
     <p>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.</p>
     <p>The DOM Inspector also displays any anonymous content that
     is part of the window. See <a href="ch07.html#77027">Chapter
     7</a> 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.</p>
     <p>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 Java-Script objects, the XBL bindings, the
     document's box model, and other information.</p>
     <h2><a name="77032"></a> The Component Viewer</h2>
     <p>The <!--INDEX Component Viewer development tool --> 
     <!--INDEX development:tools:Component Viewer --> 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
     <i>mozilla/extensios/cview</i> if you use CVS.</p>
     <p>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.</p>
     <div class="c4">
       <img src="foo.gif">
     </div>
     <p><i>Figure B-2: <a name="77004"></a></i> <i>An interface
     displayed in the Component Viewer</i></p>
     <p>In XPCOM, a single component can implement more than one
     interface. Thus, for example, the editor shell component
     (<i>@mozilla.org/editor/editorshell;1</i>) implements
     <i>nsIURIContentListener</i>, <i>nsIEditorShell</i>,
     <i>nsIEditorSpellCheck</i>, 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.</p>
     <h2><a name="77033"></a> Venkman: The JavaScript Debugger</h2>
     <p>Venkman is 
     <!--INDEX STARTRANGE==Venkman development tool --> 
     <!--INDEX STARTRANGE==development:tools:Venkman --> 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 &gt; Web
     Development menu (if it was selected during the Mozilla install
     process). Figure B-3 shows Venkman in action.</p>
     <div class="c4">
       <img src="foo.gif">
     </div>
     <p><i>Figure B-3: <a name="77006"></a></i> <i>The JavaScript
     Debugger</i></p>
     <p>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.</p>
     <p>Keyboard shortcuts for the <tt>step</tt> commands are the
     same as in other common visual debugging environments, and
     console users should be familiar with Venkman's <tt>break</tt>,
     <tt>step</tt>, <tt>next</tt>, <tt>finish</tt>, <tt>frame</tt>,
     and <tt>where</tt> commands.</p>
     <p>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 <i><a href=
     "http://www.mozilla.org/projects/venkman/">http://www.mozilla.org/projects/venkman/</a></i>
     describes these views and their modes of operation.</p>
     <p>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,
     <i>chrome://venkman/content/venkman-commands.js</i> and
     <i>chrome://venkman/content/venkman-views.js</i> will contain
     Venkman's default commands and views.</p>
     <p>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 <i><a href=
     "http://www.mozilla.org/projects/venkman/venkman-walkthrough.html">
     http://www.mozilla.org/projects/venkman/venkman-walkthrough.html</a></i>.</p>
     <ol>
       <li>
         Invoke the <tt>-venkman</tt> command-line argument by
         typing mozilla -venkman to start Mozilla.
         <p>You must start the debugger before the scripts it edits
         can be debugged. If you want to debug the file
         <i>navigator.xul</i>, 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.</p>
         <p>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.</p>
       </li>
       <li>Launch a browser window and select "Navigator" from the
       debugger's Tasks menu.</li>
       <li>
         Type break ContextMenu 357 in the debugger.
         <p>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.</p>
         <p>Or, you could select <i>nsContextMenu.js</i> from the
         Scripts View, locate line 357, and click in the left
         margin. Setting breakpoints in this way is equivalent to
         using the <tt>break</tt> command in the console.</p>
       </li>
       <li>
         Type break in the debugger.
         <p>If you don't provide arguments to the <tt>break</tt>
         command, all breakpoints are listed.</p>
       </li>
       <li>
         Create a context menu in the Navigator window.
         <p>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.</p>
       </li>
       <li>
         Type step in the debugger.
         <p>This command executes the line of JavaScript we're
         stopped on and stops again before the next line is
         executed. The <tt>step</tt> command is also available via
         the "Step Into" button on the toolbar and is bound to the
         F11 key.</p>
         <p>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,
         <tt>this.onTextInput</tt> <tt>=</tt>
         <tt>this.isTargetATextBox(elem);</tt>.</p>
       </li>
       <li>
         Type props this in the debugger.
         <p>The <tt>props</tt> command lists an object's properties.
         The letters and dashes before the values are the flags for
         that value. The flags are enumerated in <a href=
         "#77006">Figure B-3</a>, previously shown.</p>
       </li>
       <li>Step one more time.</li>
       <li>You should be in the <tt>isTargetATextBox</tt> function
       call now.</li>
       <li>
         Type frame in the debugger.
         <p>When used without arguments, the <tt>frame</tt> command
         shows you the source code for the current frame (with a few
         lines of context).</p>
       </li>
       <li>
         Type scope in the debugger.
         <p>The <tt>scope</tt> 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.</p>
       </li>
       <li>
         Type where in the debugger.
         <p>The <tt>where</tt> command lists the current call stack.
         The <tt>frame</tt> command can be used to change the
         current frame to any frame listed here. For example, to
         view variables in the code that called
         <tt>isTargetATextBox</tt>, type frame 1, and scope. To
         return to the top frame, type frame 0.</p>
       </li>
       <li>
         Type eval window._content.
         <p>The <tt>eval</tt> command evaluates arbitrary JavaScript
         in the current frame. Running the <tt>eval</tt> command on
         <tt>window._content</tt> itself isn't very useful, so
         you'll have to think of something more creative.</p>
       </li>
       <li>
         Type break.
         <p>The <tt>break</tt> command, when used without arguments,
         lists the current breakpoints by index.</p>
       </li>
       <li>
         Type clear 0.
         <p>The <tt>clear</tt> command clears breakpoints. In this
         example, we clear by breakpoint number, which we got from
         the <tt>break</tt> command in the previous step.</p>
       </li>
       <li>
         Type cont.
         <p>The <tt>cont</tt> command continues execution. The
         context menu should pop up as it always 
         <!--INDEX ENDRANGE==Venkman development tool --> 
         <!--INDEX ENDRANGE==development:tools:Venkman --> does.</p>
       </li>
     </ol>
     <h2><a name="77034"></a> MozillaTranslator</h2>
     <p><a href="ch11.html#77028">Chapter 11</a> provides 
     <!--INDEX MozillaTranslator development tool --> <!--INDEX 
     development:tools:MozillaTranslator --> 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.</p>
     <p>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.</p>
     <blockquote>
       <div class="c3">
         NOTE
       </div>
       <p>MozillaTranslator is more than just a program for
       inputting translated strings. The web site (<i><a href=
       "http://www.MozillaTranslator.org/">http://www.MozillaTranslator.org/</a></i>)
       has resources for setting up projects, uploading language
       packs, and finding the latest news on localization issues
       among other features.</p>
     </blockquote>
     <p>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:</p>
     <ol>
       <li>Select File &gt; Manage Products.</li>
       <li>Press Add in the dialog to add a package.</li>
       <li>In the window that comes up, give the project a label
       (for your own use) and point to the <i>chrome\en-US.jar</i>
       file within your Mozilla build (replace the path with your
       own Mozilla application locale path).</li>
       <li>Exit the dialog.</li>
       <li>Select File &gt; Update Product.</li>
       <li>Select Edit &gt; 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.</li>
     </ol>
     <div class="c4">
       <img src="foo.gif">
     </div>
     <p><i>Figure B-4: <a name="77008"></a></i> <i>Chrome view in
     MozillaTranslator</i></p>
     <p>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 &gt;
     Jar File/XPI Install from the menus.</p>
     <p><!--INDEX localization:tools --> 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.</p>
     <h2><a name="77035"></a> Missing Parts</h2>
     <p>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.</p>
     <h3><a name="77036"></a> Visual XUL Editors</h3>
     <p>XUL is a simple 
     <!--INDEX visual editors (development tools) --> 
     <!--INDEX development:tools:visual editors --> 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.</p>
     <p>So far, there have been at least a couple of attempts to
     create such a tool. A few projects, such as Vixen (<i><a href=
     "http://www.mozilla.org/projects/vixen/">http://www.mozilla.org/projects/vixen/</a></i>)
     and XULMaker (<i><a href=
     "http://xulmaker.mozdev.org">http://xulmaker.mozdev.org</a></i>),
     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.</p>
     <h3><a name="77037"></a> Toolkits and Libraries</h3>
     <p>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.</p>
     <p>In this book, we discussed the JSLib project (<i><a href=
     "http://jslib.mozdev.org">http://jslib.mozdev.org</a></i>),
     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.</p>
     <h3><a name="77038"></a> Integrating the Pieces</h3>
     <p>Popular development 
     <!--INDEX development:tools:integration --> 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.</p>
     <p>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.</p>
     <p>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,
     Java-Script, and all other parts of a Mozilla application that
     can then be packaged easily when you are done.</p>
     <hr>
     <!-- ?php require(NOTES); ? -->
     <?php $post_to_list=NO; require(ANNOTATE); ?>

Removed from v.1.5  
changed lines
  Added in v.1.6


FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>