1.1 Feature Requests / Tweaks

[Chris J. Karr]

First of all, congrats on getting the new version out the door. It's
very nice.

Second, after I installed the new version, my Sound Effects (built
against 0.76) plugin ceased working. I double clicked to install it,
and got the usual invitation to configure it. System Preferences opens
up, but the plugin is nowhere to be found. It is not visible under
Display Options or anywhere else.

This is not a big deal given that Growl now has support for sound
effects, too. I'm fine abandoning my plugin if the following tweaks
are made:

1. When looking for sounds, please also look in ~/Library/Sounds for
files. At the moment, Growl is just finding the system-wide sounds.

2. Please add an option for a default sound effect to be played when
the default display settings are used. The default value should
probably be "None", but having a default sound added to otherwise
unconfigured notifications is useful.

Thanks again for the hard work. I'm impressed with the new release,
especially the Applications tab. That's much cleaner and better
designed than before. Good job! If the Growl team isn't interested in
implementing the suggestions above, please let me know and I'll begin
porting my (largely redundant) plugin from 0.76 to 1.1.

-Chris

[Chris Forsythe]

On Sep 8, 2007, at 3:44 PM, Chris J. Karr wrote:

>
> First of all, congrats on getting the new version out the door. It's
> very nice.

Thanks :)

>
> Second, after I installed the new version, my Sound Effects (built
> against 0.76) plugin ceased working. I double clicked to install it,
> and got the usual invitation to configure it. System Preferences opens
> up, but the plugin is nowhere to be found. It is not visible under
> Display Options or anywhere else.
>

There's some way to make plugins compatible. Brian, can you document
this since you made it?

> This is not a big deal given that Growl now has support for sound
> effects, too. I'm fine abandoning my plugin if the following tweaks
> are made:

I would abandon it too. Come work for us instead :D

>
> 1. When looking for sounds, please also look in ~/Library/Sounds for
> files. At the moment, Growl is just finding the system-wide sounds.
>

Sounds reasonable.

> 2. Please add an option for a default sound effect to be played when
> the default display settings are used. The default value should
> probably be "None", but having a default sound added to otherwise
> unconfigured notifications is useful.
>

So something in general prefs for "play sound"? Want to take a stab
at this one for 1.2 Chris? I'd be ok with it.

> Thanks again for the hard work. I'm impressed with the new release,
> especially the Applications tab. That's much cleaner and better
> designed than before. Good job! If the Growl team isn't interested in
> implementing the suggestions above, please let me know and I'll begin
> porting my (largely redundant) plugin from 0.76 to 1.1.

I'd be happy with both of the options being available. Thanks for the
nice comment about the Apps tab as well.

Chris

[jack frost]

I've noticed that the music video display "scrolls" much more slowly
than in the 0.7.6 release. It'd be nice to have some way of adjusting
the speed for that (or just to have it be faster).

[Peter Hosey]

On Sep 08, 2007, at 15:57:13, jack frost wrote:
> I've noticed that the music video display "scrolls" much more slowly
> than in the 0.7.6 release.

Actually, it takes exactly the same amount of time: one second. It
just isn't linear anymore.

[Chris Forsythe]

Can you explain that a bit further?

Chris

[Peter Hosey]

Here's the Music Video code in 0.7.6 (Display Plugins/Music Video):

if (sizePref == MUSICVIDEO_SIZE_HUGE) {
timerInterval = (1.0 / 128.0);
fadeIncrement = 6.0f;
} else {
timerInterval = (1.0 / 64.0);
fadeIncrement = 6.0f;
}

The interval is the duration of the animation divided by the size of
the notification window (128 or 64). Thus, the duration here is one
second.

It's much clearer in the new code:

@implementation GrowlAnimation

- (id) init {
if ((self = [super init])) {
animationDuration = 1.0;

This is also in seconds.

Music Video does try to use a different default duration (four
seconds), but nothing actually uses the instance variable that it
puts the number into.

Anyway, the old code's frame rate was linear: It moved the window up
by exactly one pixel every iteration, and the iterations were
(timerInterval) seconds apart.

The new code defaults to EaseInOut and doesn't change it. Apple's
description of NSAnimationEaseInOut is:

Describes an S-curve in which the animation slowly speeds up and
then slows down near the end of the animation.

That's not what our code (which is built to emulate NSAnimation) does.

What we do is actually pretty similar to our own EaseIn curve:

[Chris Forsythe]

> <GrowlAnimationEaseInOut-75%-nq8.png>
>
> Either way, not linear.
>

Alright, that explains it. However, we're getting multiple people who
liked the older functionality rather than the newer functionality. Is
there any real benefit to the newer functionality over the old (minus
code readability)?

Chris

[Peter Hosey]

On Sep 08, 2007, at 17:30:54, Chris Forsythe wrote:
> Alright, that explains it. However, we're getting multiple people
> who liked the older functionality rather than the newer
> functionality. Is there any real benefit to the newer functionality
> over the old (minus code readability)?

It's more Delicious that way.

Certainly, our failed attempt to change the duration should be undone
—if one second (non-linearly) is too long, four seconds is *far* too
long.

Also, the mechanism for changing the duration ought to be fixed.
(Actually, GrowlAnimation should be ripped out and replaced with the
real NSAnimation, since Growl requires Tiger now. That was the plan
from even before we put it in: that we'd take it out after we started
requiring Tiger. The curve will probably change subtly when we do
that, which is fine, since I think it's wrong now.)

I prefer the new behavior myself, so I say we keep the curve and see
what the reaction is when we release 1.1.1. If people still hate it,
then we can change it back in the version after that.

[Chris Karr]

On Sep 8, 2007, at 5:43 PM, Chris Forsythe wrote:

>> 1. When looking for sounds, please also look in ~/Library/Sounds for
>> files. At the moment, Growl is just finding the system-wide sounds.
>
> Sounds reasonable.
>
>> 2. Please add an option for a default sound effect to be played when
>> the default display settings are used. The default value should
>> probably be "None", but having a default sound added to otherwise
>> unconfigured notifications is useful.
>
> So something in general prefs for "play sound"? Want to take a stab
> at this one for 1.2 Chris? I'd be ok with it.

Assuming that I'm the Chris mentioned above, I'd be happy to
contribute a patch. However, in order to do so, I'll need a little
bit of guidance getting started. I'm fine checking out the latest SVN
version and coding the changes in Xcode. However, once the changes
are made, I'm less clear on how I would export my changes as a patch
that I could send to you guys. Is this a feature built into SVN
(generate a patch with changes if commit access is unavailable) or do
I need to brush off that rusty "diff" man page?

-Chris

[Daniel Bergman]

On Sep 9, 1:35 pm, Chris Karr <cjk...@gmail.com> wrote:
> Assuming that I'm the Chris mentioned above, I'd be happy to
> contribute a patch. However, in order to do so, I'll need a little
> bit of guidance getting started. I'm fine checking out the latest SVN
> version and coding the changes in Xcode. However, once the changes
> are made, I'm less clear on how I would export my changes as a patch
> that I could send to you guys. Is this a feature built into SVN
> (generate a patch with changes if commit access is unavailable) or do
> I need to brush off that rusty "diff" man page?
>
> -Chris

The docs on how to contribute to Adium X can probably be applied to
Growl to a large extent. http://trac.adiumx.com/wiki/ContributingCode

/Daniel

[Chris Karr]

On Sep 9, 2007, at 8:24 AM, Daniel Bergman wrote:

> The docs on how to contribute to Adium X can probably be applied to
> Growl to a large extent. http://trac.adiumx.com/wiki/ContributingCode

Perfect - thanks!

However on checkout, I'm running into the following error:

svn: Can't convert string from 'UTF-8' to native encoding:
svn: Growl/Extras/GrowlMail/Instalac?\204?\167a?\204?\131o do
GrowlMail.rtf

Is this a problem on your end or mine? If it's the latter, what
options do I need to pass to SVN?

-Chris

[Chris J. Karr]

Problem solved. When using the command line SVN, the following command
needs to be run before checkout:

export LANG="en_US.UTF-8"

(Assuming an English locale.)

This may be useful to add to the developer docs for future readers.

-Chris

[Brent Neal]

On Sep 9, 2007, at 10:14, Chris Karr wrote:

> Perfect - thanks!
>
> However on checkout, I'm running into the following error:
>
> svn: Can't convert string from 'UTF-8' to native encoding:
> svn: Growl/Extras/GrowlMail/Instalac?\204?\167a?\204?\131o do
> GrowlMail.rtf
>
> Is this a problem on your end or mine? If it's the latter, what
> options do I need to pass to SVN?

I see the same error when I try to do an 'svn update' so it's not
just you.

B

--
Brent Neal
http://brentn.freeshell.org
<bre...@freeshell.org>

[Evan Schoenberg]

On Sep 9, 2007, at 10:28 AM, Brent Neal wrote:

>>
>> However on checkout, I'm running into the following error:
>>
>> svn: Can't convert string from 'UTF-8' to native encoding:
>> svn: Growl/Extras/GrowlMail/Instalac?\204?\167a?\204?\131o do
>> GrowlMail.rtf
>>
>> Is this a problem on your end or mine? If it's the latter, what
>> options do I need to pass to SVN?
>
> I see the same error when I try to do an 'svn update' so it's not
> just you.

As Chris noted, you need to set your locale info so subversion knows
how to do the string conversion. I have
export LC_ALL=en_US.UTF-8

in my .bashrc

-Evan

[bgannin]

I don't when it was added exactly, but it is listed at http://growl.info/documentation/developer/growl-source-install.php

- brian 'bgannin' ganninger

[Brent Neal]

On Sep 9, 2007, at 10:39, Evan Schoenberg wrote:

>
> As Chris noted, you need to set your locale info so subversion knows
> how to do the string conversion. I have
> export LC_ALL=en_US.UTF-8
>
> in my .bashrc
>

Awesome. Thanks.

What part of the system reads this? Is this only for subversion, or
is there a lower level system that uses this environment variable?

[Chris Forsythe]

Here's how I think we should approach it:

1) Change music video to the older .7.6 behavior that people are
clamoring for.

2) With 1.2, offer this newer functionality as an option for music
video (and perhaps others?).

Thoughts?

Chris

[Evan Schoenberg]

On Sep 9, 2007, at 3:03 PM, Chris Forsythe wrote:

Here's how I think we should approach it:

1) Change music video to the older .7.6 behavior that people are clamoring for.

2) With 1.2, offer this newer functionality as an option for music video (and perhaps others?).

Ease in-ease out is a smoother way of handling a transition.  Are we sure that 1 second duration is actually occurring in both old and new and it's just a matter of the timing curve?

[Chris Karr]

Nice. Hand me my dunce cap now. :-)

-Chris

[Evan Schoenberg]

I added it in response to Chris's email. :)

-Evan

[Chris Forsythe]

I guess we'd need to figure that out. How can we find this out?

Chris

[Evan Schoenberg]

On Sep 9, 2007, at 3:29 PM, Chris Forsythe wrote:

Ease in-ease out is a smoother way of handling a transition. Are we sure that 1 second duration is actually occurring in both old and new and it's just a matter of the timing curve?

I guess we'd need to figure that out. How can we find this out?

Stopwatch and decent reaction times with each version of Growl - if there's a big enough difference in the timing for people to be noticing, human reaction time should be good enough.

-Evan

[Peter Hosey]

On Sep 09, 2007, at 12:03:45, Chris Forsythe wrote:
>> I prefer the new behavior myself, so I say we keep the curve and
>> see what the reaction is when we release 1.1.1. If people still
>> hate it, then we can change it back in the version after that.
>
> Here's how I think we should approach it:
>
> 1) Change music video to the older .7.6 behavior that people are
> clamoring for.
>
> 2) With 1.2, offer this newer functionality as an option for music
> video (and perhaps others?).

A pref?

Fine by me.

[Peter Hosey]

On Sep 09, 2007, at 10:07:54, Brent Neal wrote:
> What part of the system reads this? Is this only for subversion, or
> is there a lower level system that uses this environment variable?

It's read by the C library and exposed as an API, which Subversion uses.

[Peter Hosey]

On Sep 09, 2007, at 12:29:52, Chris Forsythe wrote:
> I guess we'd need to figure that out. How can we find this out?

http://boredzo.org/stuph/MusicVideoTimingTest.mov

Use the Current Time in QTP's Inspector window for great justice.

Here's what you find that way:

Start: 0.56
End: 1.56

Exactly one second. QED.

[Chris Forsythe]

Now we just need 0.7.6 for comparison.

Chris

[Peter Hosey]

On Sep 09, 2007, at 19:27:26, Chris Forsythe wrote:
> Now we just need 0.7.6 for comparison.

Ah, such a good idea.

http://boredzo.org/stuph/MusicVideoTimingTest-0.7.6.mov

Start: 0.56
End: 0.86

So it IS slower! Specifically, it now takes 0.3 seconds.

I still think, from my reading of the Music Video code, that one
second was the intended behavior. I wonder what made it take half a
second.

Regardless, I'm inclined to change 1.1.1 to fix this. People clearly
prefer the old behavior.

[Chris Forsythe]

Indeed. Can you handle that one Peter? You've got a firm grasp on the
issue.

Chris

[Evan Schoenberg]

I got interested in the timing failure this morning, too, and found that there were a number of problems with the timing code.. possibly just secondary to the NSAnimation switch, since I found at least one show stopper which came from that recent change.  I fixed up the code; having done that, fixing music video is just a matter of adding a [self setTransitionDuration:] call when it is initializing.  Done :)

-Evan