I put a proposal up on http://code.google.com/p/growl/wiki/FutureGrowlInstallerPlusDMGPlans
for how I think we could change things for deployment. If some of
you could look at it and provide feedback that'd be appreciated.
Chris
Just a peanut gallery opin...
Internet-enabled DMG ... IMO not a good idea; too many problems.
This functionality is only triggered IFF you use Safari with
auto-open enabled. But basic browsing security say that you never
enable such things! And not everyone uses Safari. This creates two
very different installation experiences - which will confuse the user
and create more support issues for you. Additionally - auto deleting
products are simply not permitted in most business environments.
Extras tab... I really like the idea of moving the Extras into a
tab, within the Growl prefspane! I'm not sure of your wording tho -
is this a list of extras that let the user select which is to be
downloaded and installed? Or are the Extras stashed within the
prefspane initially (making for a bloated pane on disk) and just
activated by the user? How would one do activations / updates on a
system that has no public 'net access, ever?
- Dan.
--
- Psychoceramic Emeritus; South Jersey, USA, Earth.
Just a peanut gallery opin...
At 8:56 PM -0600 11/9/2009, Chris Forsythe wrote:
>I put a proposal up on
>http://code.google.com/p/growl/wiki/FutureGrowlInstallerPlusDMGPlans
>for how I think we could change things for deployment. If some of
>you could look at it and provide feedback that'd be appreciated.
Internet-enabled DMG ... IMO not a good idea; too many problems.
This functionality is only triggered IFF you use Safari with
auto-open enabled. But basic browsing security say that you never
enable such things! And not everyone uses Safari. This creates two
very different installation experiences - which will confuse the user
and create more support issues for you. Additionally - auto deleting
products are simply not permitted in most business environments.
Extras tab... I really like the idea of moving the Extras into a
tab, within the Growl prefspane! I'm not sure of your wording tho -
is this a list of extras that let the user select which is to be
downloaded and installed? Or are the Extras stashed within the
prefspane initially (making for a bloated pane on disk) and just
activated by the user? How would one do activations / updates on a
system that has no public 'net access, ever?
I don't think that a .pkg on an internet-enabled disk image makes much sense, though. Why not a big icon that says "Install Growl" on a window that pops up, rather than it disappearing into a Downloads folder, if we can't go with a raw file (and I agree that we can't, as a second download would be Growl-1.prefpane and we'd get duplicate installations pretty easily).
Cheers,
Evan
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Growl Development" group.
> To post to this group, send email to growl-de...@googlegroups.com
> To unsubscribe from this group, send email to growl-developm...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/growl-development?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
> Though I don't think that it's the Right solution, I'm fine breaking
> things up into separate releases, as Peter has already done with
> GrowlMail, for the sake of Getting Things Done.
>
I'm more hesitant to do it now, since we're getting people on the
discuss list confused about Growl vs GrowlMail and it's a bit more
apparent.
> I don't think that a .pkg on an internet-enabled disk image makes
> much sense, though. Why not a big icon that says "Install Growl" on
> a window that pops up, rather than it disappearing into a Downloads
> folder, if we can't go with a raw file (and I agree that we can't,
> as a second download would be Growl-1.prefpane and we'd get
> duplicate installations pretty easily).
>
With the Extras inside the prefpane, to me it makes sense. When we
changed to internet-enabled with Family for instance, we saw a drastic
reduction of support requests about unmounting the dmg for instance.
And Family doesn't have nearly the amount of users that Growl does.
I thought going pkg would solve the problem with the Growl-1.prefpane,
Growl-2.prefpane, etc etc nicely. Plus it's something users know. I'm
up for other ideas though.
> Cheers,
> Evan
>
> On Nov 9, 2009, at 8:56 PM, Chris Forsythe wrote:
>
>>
>> Folks,
>>
>> I put a proposal up on http://code.google.com/p/growl/wiki/FutureGrowlInstallerPlusDMGPlans
>> for how I think we could change things for deployment. If some of
>> you could look at it and provide feedback that'd be appreciated.
>>
>> Chris
>>
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google
>> Groups "Growl Development" group.
>> To post to this group, send email to growl-de...@googlegroups.com
>> To unsubscribe from this group, send email to growl-developm...@googlegroups.com
>> For more options, visit this group at http://groups.google.com/group/growl-development?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Growl Development" group.
> To post to this group, send email to growl-de...@googlegroups.com
> .
> To unsubscribe from this group, send email to growl-developm...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/growl-development?hl=en
> .
>
>
It makes very good sense, as when the average user downloads the image
in Safari, the Installer package will open up right away. No messing
around with a disk image.
My problem with installer packages is that:
1. Installer sucks.
2. Installer sucks.
Double click to install a prefPane makes perfect sense to me, and
anyone who can use a mouse can follow the directions to do so. The
only real problem we have with that is the issue of upgrading, since
currently an upgrading user and a first-time install user are faced
with the same steps, and the result is that since System Preferences
might already be open, there's the potential for serious conflicts as
the old bundle isn't unloaded from System Preferences' address space.
Moving to a modern updater - that is, Sparkle 1.5 - will address this.
Only a tiny percentage of users - primarily folks who are either (1)
so confused as to probably screw something else up anyways or (2)
savvy enough to deal with it - are going to be downloading &
installing on top of an old version.
-Evan
My problem with installer packages is that:On Mon, Dec 28, 2009 at 11:18 AM, Christopher Forsythe <ch...@growl.info> wrote:
>
>
> On Sun, Dec 27, 2009 at 8:04 PM, Peter Hosey <p...@growl.info> wrote:
>>
>> On Dec 27, 2009, at 16:41:16, Evan Schoenberg, M.D. wrote:
>> > I don't think that a .pkg on an internet-enabled disk image makes
>> > much sense, though.
>>
>> It makes very good sense, as when the average user downloads the image
>> in Safari, the Installer package will open up right away. No messing
>> around with a disk image.
>>
>
> Does it make sense with what Peter said here? Any other ideas outside of
> "drag this here"?
> We do have "drag this here" with Perian and it also works pretty
> well. http://www.flickr.com/photos/greyfodder/258271552/ is a screenshot of
> that with .5 before the
> prefpane, http://allforces.com/2009/01/14/flvs-in-quick-look/ is a
> screenshot of it with the prefpane like we have it currently.
> If we're trying to make things simpler, I don't know which is the better
> route to take. To be honest I want to make this as simple as possible, and
> whatever choice we ultimately make has that goal in mind.
1. Installer sucks.
2. Installer sucks.
Double click to install a prefPane makes perfect sense to me, and
anyone who can use a mouse can follow the directions to do so. The
only real problem we have with that is the issue of upgrading, since
currently an upgrading user and a first-time install user are faced
with the same steps, and the result is that since System Preferences
might already be open, there's the potential for serious conflicts as
the old bundle isn't unloaded from System Preferences' address space.
Moving to a modern updater - that is, Sparkle 1.5 - will address this.
Only a tiny percentage of users - primarily folks who are either (1)
so confused as to probably screw something else up anyways or (2)
savvy enough to deal with it - are going to be downloading &
installing on top of an old version.
I don't think that a .pkg on an internet-enabled disk image makes much sense, though. Why not a big icon that says "Install Growl" on a window that pops up, rather than it disappearing into a Downloads folder, if we can't go with a raw file (and I agree that we can't, as a second download would be Growl-1.prefpane and we'd get duplicate installations pretty easily).
Cheers,
Evan
On Nov 9, 2009, at 8:56 PM, Chris Forsythe wrote:
>
> Folks,
>
> I put a proposal up on http://code.google.com/p/growl/wiki/FutureGrowlInstallerPlusDMGPlans
> for how I think we could change things for deployment. If some of
> you could look at it and provide feedback that'd be appreciated.
>
> Chris
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Growl Development" group.
> To post to this group, send email to growl-de...@googlegroups.com
> To unsubscribe from this group, send email to growl-developm...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/growl-development?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
--
You received this message because you are subscribed to the Google Groups "Growl Development" group.
To post to this group, send email to growl-de...@googlegroups.com.For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.
To unsubscribe from this group, send email to growl-developm...@googlegroups.com.
What's wrong with it, specifically?
What, put the version number in all the class names? The requisite
macro magic to automate that would make the code even harder to read
than CFification did.
> On Jan 5, 2010, at 13:23:21, Christopher Forsythe wrote:
>> Is there any way we can get around that by say, versioning all
>> methods/classes/whatever else?
>
> What, put the version number in all the class names?
Yea
> The requisite macro magic to automate that would make the code even
> harder to read than CFification did.
Alright, not an option :)
Chris
Well, for example, it doesn't deal with multiple existing installations in a way that is at all obvious when performing an upgrade: It replaces one, without saying which it is replacing, and leaves the other in place. I've ran into situations when it didn't run preflight or postflight scripts as requested, though I don't have an example case on me and don't want to try to reproduce it right now.
I dont have any strong objections to using it, ultimately.
-Evan