Phonon + Volume Changes and feedback loops

[Christian Esken]

Am Montag, 29. März 2010 22:23:23 schrieb Colin Guthrie:
> 'Twas brillig, and Christian Esken at 29/03/10 16:43 did gyre and gimble:
> > Am Montag, 29. März 2010 12:04:13 schrieb Colin Guthrie:
> >> 'Twas brillig, and Christian Esken at 29/03/10 10:55 did gyre and gimble:
> >>> KMix faces exactly the same challenge (for the Slider), and it simply
> >>> uses blockSignal() (see mdwslider.cpp).
> >> 
> >> Ahh interesting. I'll look into blockSignal() usage but I'm not sure if
> >> it'll work due to the async nature of some updates. Certainly worth me
> >> looking at tho'.
> >> 
> >>> The basic point is, that 2 -> 3 should be avoided. I don't see any
> >>> reason to update the volume to the GUI after a change comes in from
> >>> the Hardware or PA. We know that the value is already correct. Why is
> >>> this done?
> >> 
> >> It's needed because the change can be triggered externally to the GUI in
> >> question. e.g. to use kmix as an example: if the user uses alsamixer to
> >> change the alsa volume, the kmix GUI should be updated. The same is true
> >> in the case of per-application volumes with PA. e.g. the volume dial in
> >> amarok should be updated when the user changes the amarok stream volume
> >> in the kmix "Playback Streams" tab.
> > 
> > But that is 1 -> 2  (Update GUI). Surely that one is needed.
> > I discussed the 2 ->3 step.
> 
> Yeah sorry, I think I was confused by the phrase "I don't see any reason
> to update the volume to the GUI" which I took to mean the GUIs
> representation of the current volume. I think I basically misundersood
> and we're pretty much in agreement here :)
> 
> >> When the change comes in, we have to make sure the GUI shows that
> >> change, but that we do not push the change back to the h/w or PA again
> >> if the change that updated the GUI did not come from user input to the
> >> GUI... bah! Go go gadget poor explanation again :p
> > 
> > Exactly.
> > 
> >> I think the current protection I added in phonon with the following
> >> commit:
> >> http://gitorious.org/phonon/phonon/commit/801c316c7afa324e99406d65451e9
> >> e5ae badb213
> > 
> > Can't take a look, as currently http://gitorious.org/ seems to be
> > overloaded or down. Will try to do so later.
> 
> Yeah some sort of emergency reboot:
> http://blog.gitorious.org/2010/03/29/emergency-reboot-2/
> 
> >> solves this issue for me in my tests... but if blockSignal() works
> >> better then I'll look into using that instead.
> > 
> > I think blockSignal() would be exactly what you need.
> 
> I had a quick look at the blockSignals() docs and it seems that after
> turning it off, I'd need to turn it back on somehow (e.g. there is no
> "block one setValue signal" capability). With the current solution
> linked above, I turn the handling back on after ignoring a change but to
> do that I have to do it in the slot for that change. With blockSignals()
> I'd have to find a way to unblock them again after one has been thrown
> away.... I couldn't see a way to do that, but perhaps I missed that?

Usually you do:

slider->blockSignals( true );  // block
slider.setValue( ...) ; // do your GUI change
slider->blockSignals( false ); // unblock

Should work for your case, as you can do all of that in the same slot.
Or I haven't understod the issue fully yet. ;)

 Christian

_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia