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.
Actually, this install.js is for the Mozilla calendar. (Its in CVS at
mozilla/calendar) OEone doesn't use XPI since we only run on Linux. (I'm
trying to convince people here that we should still use it).
>
>
>>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.
The returnval's are only there for when I needed to alert them.
>
> 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.
I think that describes the calendar quite well. The XUL/JS/CSS stuff is
all XP, but there are specific items for each platform when it comes to
the XPCOM.
>
> 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
>
>
