Re: Seasonal decorations

[fcm4711]

Hi Phil, Kevin and Dean

I love that Snow Screensaver!

Please find attached a patch for Snow.pm to allow
different settings (Snow quantity, Snow style) for
different players.

Felix

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

[Phil Barrett]

Hi Felix

On 15 Dec 2003, at 20:48, Felix Mueller wrote:
> I love that Snow Screensaver!

Good to hear. Thanks!

> Please find attached a patch for Snow.pm to allow
> different settings (Snow quantity, Snow style) for
> different players.

Excellent, thanks. Some of us don't have the luxury of more than one
player... yet ;-)

Phil

[Phil Barrett]

On 15 Dec 2003, at 20:48, Felix Mueller wrote:
> Please find attached a patch for Snow.pm to allow
> different settings (Snow quantity, Snow style) for
> different players.

Actually, the patch doesn't go far enough. It works for style, but
there are other variables which remain shared between all instances of
the screensaver:
@flakes - the array of snowflakes
$lastTime - the time the flakes last moved
$wasDoubleSize - the flag to note remember whether the display was in
doublesize

Unless these are also converted with a {$client} the players' savers
won't be independent, and the now-separated snow quantity setting won't
work (each player will be adding flakes to the same shared snow).

Felix, could you look at this please?

Thanks

Phil

[kdf]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> On 15 Dec 2003, at 20:48, Felix Mueller wrote:
> > Please find attached a patch for Snow.pm to allow
> > different settings (Snow quantity, Snow style) for
> > different players.
>
> Actually, the patch doesn't go far enough. It works for style, but
> there are other variables which remain shared between all instances of
> the screensaver:
> @flakes - the array of snowflakes
> $lastTime - the time the flakes last moved
> $wasDoubleSize - the flag to note remember whether the display was in
> doublesize
>
> Unless these are also converted with a {$client} the players' savers
> won't be independent, and the now-separated snow quantity setting won't
> work (each player will be adding flakes to the same shared snow).
>
> Felix, could you look at this please?

This patch should do the trick. I cleaned up the whitespace a bit as well.
-kdf

[kdf]

updated the patch. last one had a bothced $lastTime setup.

-kdf

[Phil Barrett]

On 16 Dec 2003, at 09:03, kdf wrote:
> updated the patch. last one had a bothced $lastTime setup.

and in the CVS comment:
> throw somethign at me if there is still more

I'm not convinced the multi-player support is quite right yet - you
have a scalar $flakes_ref which is [re]set each time a player enters
the screensaver. I'm not entirely sure why it's needed at all, but if
it is I guess it needs to be a hash of references to arrays of hashes,
those arrays being the ones stored in %flakes, which is a hash of
arrays of hashes. Gotta love Perl!

There will be other snowy enhancements shortly, when I get some time.
And I might even get round to finishing the lyrics display as a
screensaver.

Phil

[kdf]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> On 16 Dec 2003, at 09:03, kdf wrote:
> > updated the patch. last one had a bothced $lastTime setup.
>
> and in the CVS comment:
> > throw something at me if there is still more
>
> I'm not convinced the multi-player support is quite right yet - you
> have a scalar $flakes_ref which is [re]set each time a player enters
> the screensaver. I'm not entirely sure why it's needed at all, but if
> it is I guess it needs to be a hash of references to arrays of hashes,
> those arrays being the ones stored in %flakes, which is a hash of
> arrays of hashes. Gotta love Perl!

There might be a better place for it. Basically, I needed a way of initialising
with the $client key. I can't do that outside of a subroutine since $client
does not exist globally. Hence, its a hash reference to an array of hashes and
a partridge in a pear tree... It should be ok to reset upon entry, since the
screensaver does not re-enter its mode once engaged. I had it in the letitsnow
routine at first, which was interesting..more like a meteor shower with them all
disappearing before hitting bottom

>
> There will be other snowy enhancements shortly, when I get some time.
> And I might even get round to finishing the lyrics display as a
> screensaver.

that's the idea
there are some improvements to teh animation for just such a thing. You can set
the client params for scrollRate and scrollPause to control timing, as well as
animateTop to choose either the static first line or the updating version.

However, as Robert pointed out, you can write custom calls to
animateWindowOverlay if needed. Look at the animateScrollBottom routine for an
example of how to set up a wrapper. I'm still looking at ways to improve the
animation routines, but its a steep learning curve. you may get it before i do

-kdf

[Phil Barrett]

On 16 Dec 2003, at 20:12, kdf wrote:
> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>> I'm not convinced the multi-player support is quite right yet - you
>> have a scalar $flakes_ref which is [re]set each time a player enters
>> the screensaver. I'm not entirely sure why it's needed at all, but if
>> it is I guess it needs to be a hash of references to arrays of hashes,
>> those arrays being the ones stored in %flakes, which is a hash of
>> arrays of hashes. Gotta love Perl!
>
> There might be a better place for it. Basically, I needed a way of
> initialising
> with the $client key. I can't do that outside of a subroutine since
> $client
> does not exist globally. Hence, its a hash reference to an array of
> hashes and
> a partridge in a pear tree... It should be ok to reset upon entry,
> since the
> screensaver does not re-enter its mode once engaged.

Sure? Even if player 2 starts the screensaver while player 1 is already
in it?

> I had it in the letitsnow
> routine at first, which was interesting..more like a meteor shower
> with them all
> disappearing before hitting bottom

But letItSnow knows about $client, and is the only place %flakes is
referenced, so why can't you just use @{$flakes{$client}} where I
originally had @flakes, instead of messing around with $flakes_ref?

>> There will be other snowy enhancements shortly, when I get some time.
>> And I might even get round to finishing the lyrics display as a
>> screensaver.
>
> that's the idea
> there are some improvements to teh animation for just such a thing.
> You can set
> the client params for scrollRate and scrollPause to control timing, as
> well as
> animateTop to choose either the static first line or the updating
> version.
>
> However, as Robert pointed out, you can write custom calls to
> animateWindowOverlay if needed. Look at the animateScrollBottom
> routine for an
> example of how to set up a wrapper. I'm still looking at ways to
> improve the
> animation routines, but its a steep learning curve. you may get it
> before i do

We'll see. One quick question - since I'll want to do all my own
animation, how do I prevent lines() being called from update() and the
result overwriting my handiwork? Do I simply not call $client->lines()
from my plugin?

And I'm sure once it's working the first question will be "why do I
have to wait until the screensaver kicks in before I can see the
lyrics?"

Phil

[kdf]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:


> > There might be a better place for it. Basically, I needed a way of
> > initialising
> > with the $client key. I can't do that outside of a subroutine since
> > $client
> > does not exist globally. Hence, its a hash reference to an array of
> > hashes and
> > a partridge in a pear tree... It should be ok to reset upon entry,
> > since the
> > screensaver does not re-enter its mode once engaged.
>
> Sure? Even if player 2 starts the screensaver while player 1 is already
> in it?
maybe it needs another level of hashing...
>

> But letItSnow knows about $client, and is the only place %flakes is
> referenced, so why can't you just use @{$flakes{$client}} where I
> originally had @flakes, instead of messing around with $flakes_ref?

can't remeber the exact syntax of what I tried now. it was 2am at the time.
However, what I got was a lot of flakes at the top that kept disappearing. Feel
free to patch and send up a diff. Anyone with cvs access can commit it for you.
There is little I can do about it for a few hours myself.

>
> >> There will be other snowy enhancements shortly, when I get some time.
> >> And I might even get round to finishing the lyrics display as a
> >> screensaver.
> >
> > that's the idea
> > there are some improvements to teh animation for just such a thing.
> > You can set
> > the client params for scrollRate and scrollPause to control timing, as
> > well as
> > animateTop to choose either the static first line or the updating
> > version.
> >
> > However, as Robert pointed out, you can write custom calls to
> > animateWindowOverlay if needed. Look at the animateScrollBottom
> > routine for an
> > example of how to set up a wrapper. I'm still looking at ways to
> > improve the
> > animation routines, but its a steep learning curve. you may get it
> > before i do
>
> We'll see. One quick question - since I'll want to do all my own
> animation, how do I prevent lines() being called from update() and the
> result overwriting my handiwork? Do I simply not call $client->lines()
> from my plugin?
I'm working on that. I have submitted a patch that allows uses a param
"noUpdate" to prevent the natural client->update routine. The other way is as I
had suggeste before by tricking lastIRtime. Its the screensaver control that
does the automatic updates most of the time.

>
> And I'm sure once it's working the first question will be "why do I
> have to wait until the screensaver kicks in before I can see the
> lyrics?"
set the screensaver timeout to Zero and you wont have to
this can even be an option of the screensaver itself. When its activated, it
sets the timout to zero, or 1 second.

-kdf

[kdf]

ok, ref was definately overkill in teh wrong direction...
does this patch seem a bit more reasonable?

-kdf