Pete, some comments:

With the Communicator suite, we're deliberately using multiple
contents.rdf files to make life easier for us as we compose packages,
i.e., so that we don't have to clobber or overwrite the contents.rdf
file when a new package gets added (like we were doing before with the
modern skin RDF file in order to get AIM in).   For simpler apps (i.e.,
most everybody else), you can still get away with a single RDF file like
before.  In fact, I wouldn't recommend that most apps follow
Communicator's example, since you're probably only dealing with a single
package, and you aren't having to worry about supporting two builds
(commercial vs. mozilla).

The directory structure within the JAR is completely flexible.  You
don't have to match the subdirectory structure we're using.  You can
make up your own if you want.  Heck, you can put all the files at the
top level if you want.

Apps that don't care about localizability don't have to have a locale at
all.  Similarly, apps that don't care about having multiple skins don't
have to have a skin at all.  I think it's important for that to be
mentioned, since app writers may just want to hardcode a particular look
(or language) for their apps.  You only need to register all three types
if you plan on supporting multiple locales and skins.  You can even just
have a content portion to your app and then load the global skin
stylesheets to get your pluggable looks and feels.

Your comment at the bottom of the page makes it clear to me that you
have problems with the current system. We know it's too complicated, but
right now we're hamstrung by Netscape 6, and we aren't being allowed to
change it any further.  What you're seeing is a mess right now, because
we're trapped midway between the old way and a newer way that's going to
be simpler (but isn't yet because we're not being allowed to do any more
work on it).

We're working towards evolving the installed-chrome file into a new file
type called a XAP (XUL application) file.  The idea is that you'd
double-click on a XAP file and launch an app.  The XAP file would be a
simple text file that would list the chrome packages that should be used
and the components that would be loaded.

The syntax will also be simplified, e.g., you won't have to say nearly
as much in the XAP file, e.g., you'll just list a set of paths to chrome
files, and I'd register everything I found there.  I hope to eventually
even make the RDF files not be a requirement (unless you want to specify
your package/skin/locale name/author/preview info or dynamic overlays).

Remember, this is all work on "mozilla the platform", and so Netscape
doesn't care about it right now.  Maybe once the pressure is off
Netscape management to shove a browser out the door, they'll be more
interested in the idea of a platform, but right now they just don't
care.  Given how long it's been since we shipped a browser, who can
blame them? :)

We'll be targeting these changes and improvements to packaging at
Mozilla 1.0 (along with change to XUL and XBL to bring them up to 1.0,
changes that will likely even make Mozilla 1.0 XUL and XBL incompatible
with Netscape 6).  Mozilla 1.0 will be the base from which real XUL apps
will be developed.  Netscape 6 is just a browser built on top of an 0.x
platform that has not been finalized.  So have patience.  The system
will be simplified as we approach the real 1.0 of the platform.


Questions or comments not answered in the FAQ can be submitted from our feedback page.
Copyright © 2000-2018. All rights reserved. Terms of Use & Privacy Policy.