paramstack

[Triode]

To conclude my observations on this subject [before I go and figure out how to fix my problem....]

At present the modeParamStack stores whatever param hash it is passed by pushMode. This means that it depends how the mode itself
defines the params, whether you can set new params in the mode which don't persit for every new instance of that mode.

Any mode which creates a param hash in init and then passes this in a pushMode will suffer the problem that the params for the
pushed mode are actually shared for all future instances of that mode. It seams reasonably random which modes do this. Examples
are:
- Slim::Buttons::Volume
- Slim::Buttons:AlarmClock

Whereas Slim::Buttons::XMLBrowser is safe as it creates a new param hash within its setMode before calling pushMode.

So I conclude that it is dangerous to set params for a mode unless you own that mode and are happy that the param values may persit
to the next instance of that mode...

There seems no easy way to clone the param stack to avoid this. So for the moment any dynamic state which is associated with a
specific instance of a mode, but it not under direct control of that mode [in my case how to display 2 screens] needs to be stored
somewhere else.

Adrian

[Triode]

I was planning to fix my issue with a display specific mode stack, but I wondered if it would be more useful to have a more generic
solution.

My proposal is that we have a new mode "variable" stack for storing variables which are associated with a specific instance of a
mode.

It would be accessed using $client->modeVariable() in the same way as $client->modeParam() works.

Does this seem sensible or should I do my own thing for the display code?

[I think I'm talking to myself here...]

Adrian

[Dan Sully]

* Triode shaped the electrons to say...

>I was planning to fix my issue with a display specific mode stack, but I
>wondered if it would be more useful to have a more generic solution.
>
>My proposal is that we have a new mode "variable" stack for storing
>variables which are associated with a specific instance of a mode.
>
>It would be accessed using $client->modeVariable() in the same way as
>$client->modeParam() works.

Yes - that seems much more reasonable.

>Does this seem sensible or should I do my own thing for the display code?

I'd prefer a reusable solution.

>[I think I'm talking to myself here...]

Sorry - I get lost in all the param / stack / mode / INPUT code.

-D
--
<noah> I used to be indecisive, but now I'm not sure.

[Grotus]

Modes should create a new hash when they do a setMode, otherwise
multiple players will be accessing the same hash.
Slim::Buttons::Volume, Slim::Buttons::AlarmClock, and any other mode
which is using a module level param hash need to be changed.

Values which will be the same in all instances of that mode, regardless
of the player can either be hard coded in the setMode() procedure, or
put in a module level hash which is copied into a local hash.

Hardcoded example:

sub setMode {
my $client = shift;
my $method = shift;
if ($method eq 'pop') {
Slim::Buttons::Common:opMode($client);
return;
}
my %params = ( 'param1' => 'something',
'param2' => \&someFunct,
);
Slim::Buttons::Common:ushMode($client,'INPUT.blah',\%params);
}

Copied example:
my %standardParams = ( 'param1' => 'something',
'param2' => \&someFunct,
);

sub setMode {
my $client = shift;
my $method = shift;
if ($method eq 'pop') {
Slim::Buttons::Common:opMode($client);
return;
}
my %params = %standardParams;
$params{'param3'} = $client->something;
Slim::Buttons::Common:ushMode($client,'INPUT.Blah',\%params);
}

Triode wrote:
> To conclude my observations on this subject [before I go and figure out
> how to fix my problem....]
>
> At present the modeParamStack stores whatever param hash it is passed by
> pushMode. This means that it depends how the mode itself defines the
> params, whether you can set new params in the mode which don't persit
> for every new instance of that mode.
>
> Any mode which creates a param hash in init and then passes this in a
> pushMode will suffer the problem that the params for the pushed mode are
> actually shared for all future instances of that mode. It seams
> reasonably random which modes do this. Examples are:
> - Slim::Buttons::Volume
> - Slim::Buttons:AlarmClock
>
> Whereas Slim::Buttons::XMLBrowser is safe as it creates a new param hash
> within its setMode before calling pushMode.
>
> So I conclude that it is dangerous to set params for a mode unless you
> own that mode and are happy that the param values may persit to the next
> instance of that mode...
>
> There seems no easy way to clone the param stack to avoid this. So for
> the moment any dynamic state which is associated with a specific
> instance of a mode, but it not under direct control of that mode [in my
> case how to display 2 screens] needs to be stored somewhere else.
>
> Adrian
>
>

[Grotus]

Robert Moser wrote:
> Modes should create a new hash when they do a setMode, otherwise
> multiple players will be accessing the same hash. Slim::Buttons::Volume,
> Slim::Buttons::AlarmClock, and any other mode which is using a module
> level param hash need to be changed.

From looking at it, it doesn't appear that Slim::Buttons::AlarmClock
has a problem. It copies the module level hash into a localized hash
before passing that localized hash to pushMode. Only
Slim::Buttons::Volume was incorrectly using a module level hash. I'll
have a look at the plugins now to see if any of them have a problem.

[Triode]

> Modes should create a new hash when they do a setMode, otherwise multiple players will be accessing the same hash.
> Slim::Buttons::Volume, Slim::Buttons::AlarmClock, and any other mode which is using a module level param hash need to be changed.
>
> Values which will be the same in all instances of that mode, regardless of the player can either be hard coded in the setMode()
> procedure, or put in a module level hash which is copied into a local hash.
>

Thanks Robert - I've taken my alternative modeVariable out based on the change to Volume which now works as I expected it to
originally!

Adrian