On Feb 25, 2009, at 6:43 PM, Quinn Taylor wrote:
> > On Feb 25, 2009, at 10:47 AM, Peter Hosey wrote: > >> On Feb 25, 2009, at 10:42:56, Quinn Taylor wrote: >>> Is there interest in having a unified installer that allows users >>> to select these options? >> >> Yeah. I believe that it's very common for users to update their Growl >> but forget to update GrowlMail, GrowlSafari, etc. A metapackage that >> brought all of them together would be very nice. >> >> (Custom installation option a must, of course.) >> >>> If so, I might be able to dedicate a few cycles to the cause... >> >> That would be awesome. > > > Can do. You got me interested, so here's what I've got so far: > > http://delphos.cs.byu.edu/~quinn/Growl-1.1.4.dmg > Awesome initiative Quinn. > You'll notice that when you download the DMG, it automatically > decompresses and launches Installer.app, Is this something that's regarded as "the apple way" and/or something that we won't get complaints about? > which I think will significantly simplify the install process. I > created this disk image by placing the Growl 1.1.4.mpkg in a > directory called Growl-1.1.4 and executing the following commands: > > $ hdiutil create -srcfolder Growl-1.1.4 -volname Growl-1.1.4 > Growl-1.1.4.dmg > $ hdiutil internet-enable -yes Growl-1.1.4.dmg > Can our scripts to build the disk image be modified to do that? Check out the Release directory. > (Obviously, there's huge potential for scriptability and version > number replacement. Once could even integrate it into the Xcode > build process as a script phase in a Deploy target.) > > If anyone is interested in the source material for the installer, > here is my work folder for PackageMaker 3. > > http://delphos.cs.byu.edu/~quinn/Growl-Installer.zip > > CAVEAT: I haven't yet included anything that checks whether Mail or > Safari are running before installing GrowlMail or GrowlSafari, > respectively. Also, I don't think I've completely replicated the > current Growl install—I'm not sure whether the helper app is > started, etc. > > Feedback? This is a good start, there is a lot of work ahead of course. I think the problem with our installation is that it has been bantied back and forth between multiple different approaches, and we need a solid one. This is a good idea, installing all of the applications for the end user. If we're going to redo the installation, we should change it one last time, get it right, and then leave it be. Other packages we've all worked on is the Adium package and the Perian package, all of which use a variation of the Release directory building scripts. The Adium package works since it's an application. The emphasis is on the installation action itself, with the ancillary bits (license, changes) out of the way. It's also good looking, which helps. The Perian disk image again focuses on installation, but in a different way, since installation is different. I don't know about Adium anymore, but with regards to Perian, we don't have people reporting issues about installing the prefpane itself, which is where I want things to go with Growl. I think this, growltunesplugin, and the communications stack changes are the highest priority items to work on, so it's great that someone has come forward who is passionate about it. Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Growl Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en -~----------~----~----~----~------~----~------~--~---
