So, to sum this whole thing up... Here's what I've now got.
I've got a directory structure like this:
resources/
content/
locale/
skin/
linuxcomponents/
windowscomponents/
linuxinstall.js
windowsinstall.js
The linuxinstall.js files look like this: (windows just change
linuxcomponents to windowscomponents)
initInstall("Mozilla Calendar", "Mozilla/Calendar", "0.7");
calendarDir = getFolder("Chrome","calendar");
setPackageFolder(calendarDir);
addDirectory( "resources" );
addDirectory("", "linuxcomponents", getFolder( "Components" ), "" );
var err = getLastError();
if ( err == SUCCESS ) {
registerChrome(CONTENT, calendarDir, "content");
registerChrome(SKIN, calendarDir, "skin/modern");
registerChrome(LOCALE, calendarDir, "locale/en-US");
err = performInstall();
if ( err == SUCCESS ) {
refreshPlugins();
alert("The Mozilla Calendar has been succesfully installed. \n"
+"Please restart your browser to continue.");
}
else {
alert("performInstall() failed. \n"
+"_____________________________\nError code:" + err);
cancelInstall(err);
}
}
else {
alert("Failed to create directory. \n"
+"You probably don't have appropriate permissions \n"
+"(write access to mozilla/chrome directory). \n"
+"_____________________________\nError code:" + err);
cancelInstall(err);
}
Then, I make two .xpi files, one for windows and one for linux, which
contains resources and the appropriate components directory.
Is that correct? (And is it the best way to package for different
platforms?)
Mike
Daniel Veditz wrote:
> 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
>
>
