Bugzilla – Bug 9253
Prefs which need to call a sub to take effect on change need a onChange handler
Last modified: 2009-07-31 10:27:56 UTC
We have several prefs which need to runs some command to actually take effect when they are changed. We have to add code in several places (Buttons/Settings, Control/Jive, Web/Settings) to make sure this is all working fine. That's ugly and prone to errors. All these prefs should have an onChange handler instead which does this call. Jive.pm should not need to have subs like: sub playerTextAdjustCommand { my $request = shift; my $client = $request->client(); my $newVal = $request->getParam('value'); my $val = $client->textSize($newVal); $request->setStatusDone(); } (Ben - please correct me if my assumption that the above would be obsolete with an onChange handler is wrong) Or in the button's settings modes: 'TREBLE' => { 'useMode' => 'INPUT.Bar', 'header' => 'TREBLE', 'stringHeader' => 1, 'headerValue' => 'unscaled', 'cursor' => 0, 'min' => sub { shift->minTreble(); }, 'max' => sub { shift->maxTreble(); }, 'increment' => 1, 'onChange' => \&executeCommand, 'command' => 'mixer', 'subcommand' => 'treble', 'initialValue' => sub { return $_[0]->treble() }, 'condition' => sub { my $client = shift; return $client->maxTreble() - $client->minTreble(); }, }, All that code belongs in one place which is called whenever a pref is changed.
as mentioned in another bug, INPUT.* should be making the pref change only (perhaps simply having a "pref" key and let the modes to the setting if present. Then the setChange does the rest. This should help consolidate UIs
No argument here...we need this. I think this is reasonable to target for 7.3
This will need more work as we go ahead. But with change 23272 et al. all occurences in Jive.pm and S::B::Settings.pm should be fixed. The example I mentioned wasn't a good one: mixer commands imho are ok.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Why is this needed? I'm looking at making the displayed volume be the volume of the amp/receiver, while leaving the player at a fixed volume (see bug 9804), and the setChange handler for 'volume' that was added in 23250 is getting in the way. Couldn't the official code just call 'mixer volume' instead of relying on the volume being changed immediately to match the volume pref?
> Why is this needed? Pretty well summarized in the initial bug description, isn't it? :-) > the official code just call 'mixer volume' instead of relying on the volume > being changed immediately to match the volume pref? From "mixer volume": if ($entity eq 'volume' && defined $client->tempVolume && $client->tempVolume == 0 && $oldval > 0) { # only set pref as volume is temporarily set to 0 $prefs->client($client)->set('volume', $newval) if ($newval <= $client->maxVolume); } else {
Reduce number of active targets for SC