Mike Potter wrote:
> Here is the script which works for Linux...
>
> ---------------------------------BEGIN---
> initInstall("Mozilla Calendar", "/Mozilla/Calendar", "0.7");
"/Mozilla/Calendar" is not a great choice for a registry name. The main
problem is that initial '/' turns it into an absolute registry path, but
also because the name is pretty generic. If someone else writes a Calendar
app they might well pick the same name and then both apps could confuse each
other over which one was up to date.
Generally I recommend something like <company or author>/<product>, so in
your case perhaps "OEOne/Calendar" (note no leading slash). If you want to
claim to be the "one true calendar" you could try squatting on plain
"Calendar". That's likely to be what mozilla.org would use for whatever
calendar package they might ship. I know OEOne donated source to
mozilla.org, but I suspect what you're shipping doesn't match exactly.
> calendarDir = getFolder("Chrome","calendar");
>
> setPackageFolder(calendarDir);
>
> var err = addDirectory("", "resources", getFolder("Chrome","calendar"),
> "" );
Replace the getFolder() call here with the calendarDir variable you've
already got, or even, since you've set the default package folder, use the
most abbreviated form: addDirectory("resources");
> addDirectory("", "components", getFolder( "Components" ), "" );
>
> if ( err == SUCCESS ) {
You check one return value and not the other. Maybe don't check either
addDirectory call directly and instead do
var err = getLastError();
if ( err == SUCCESS ) {
> var calendarContent = getFolder(calendarDir, "content");
> var calendarSkin = getFolder(calendarDir, "skin");
> var calendarLocale = getFolder(calendarDir, "locale");
>
> var returnval = registerChrome(CONTENT | DELAYED_CHROME,
> calendarContent );
> var returnval = registerChrome(SKIN | DELAYED_CHROME, calendarSkin,
> "modern/");
> var returnval = registerChrome(LOCALE | DELAYED_CHROME,
> calendarLocale, "en-US/");
You're not looking at returnval; just drop it and unclutter your script.
Eventually you might want to ship chrome archived in jarfiles. If that's a
possibility you might want to structure your script now to support that,
which requires that the second arg 'folder' object point at the archive
registerChrome(CONTENT, calendarDir, "content");
registerChrome(SKIN, calendarDir, "skin/modern");
registerChrome(LOCALE, calendarDir, "locale/en-US");
I've dropped the DELAYED_CHROME chrome type because I'm not sure why you
need it. Yeah, users will probably have to restart anyway to use the new
package because of XUL caching, but someday it may work.
> err = performInstall();
> if ( err == SUCCESS ) {
> alert("The Mozilla Calendar has been succesfully installed. \n"
> +"Please restart your browser to continue.");
At this point you could add a refreshPlugins() call. SHOULD if you take out
DELAYED_CHROME because you don't want the user trying to start up your app
if the components aren't registered yet. Unlikely case, but if XUL caching
is turned off this could happen.
> I was thinking that all the files for both installs will go in one XPI,
> so I thought that I had to know the platform in order to say something
> like, "If you're on Windows, then install the dll files, otherwise we
> don't need to install them."
You could do that, but as a modem user I think it's unkind to make people
download binaries they don't need. The platform property is most useful if
the thing you're installing is overwhelmingly cross-platform with a small
platform-specific component, or if you make platform-specific packages but
want to re-use the same script to keep development/testing effort down.
If you do ship binaries for multiple platforms you need to have separate
wincomponents and linuxcomponents directories in your script above in
addition to the extra files windows puts in the "Program" directory.
-Dan Veditz
