#7248 NORM Update.: Speaker device has inconsistent behavior

[Zarro Boogs per Child]

#7248: Speaker device has inconsistent behavior
---------------------+------------------------------------------------------
  Reporter:  Eben    |       Owner:  mtd                              
      Type:  defect  |      Status:  new                              
  Priority:  normal  |   Milestone:  Update.2 (8.2.0)                 
 Component:  sugar   |     Version:  Development build as of this date
Resolution:          |    Keywords:                                   
  Verified:  0       |    Blocking:                                   
 Blockedby:          |  
---------------------+------------------------------------------------------

Comment(by mtd):

 Replying to [ticket:7248 Eben]:
 > After updating to the latest joyride, I'm noticing a number of
 inconsistencies in the behavior of the speaker device:
 >
 >  1. The speaker icon only ever appears at the 000 and 100 levels; the
 intermediate levels all appear as 100.

 1. Should be easy -- appears to be a problem with get_icon_state() or how
 I'm calling it, as I'm certainly asking it for the icon to do with the
 current volume level

 >  2. Frequently, after having muted the speakers, the simple act of
 revealing the palette for the device will un-mute it unintentionally.


 2. Not sure what's going on here but it sounds like some brain dead error
 in the code that should be easy to fix


 >  3. On occasions when I can reveal the palette without un-muting it, I
 find that dragging the volume slider a) only occasionally changes the
 appearance of the icon back to un-muted (colored) and b) never changes the
 Un-mute menu option back to Mute.


 3. I am probably mis-remembering, but I thought we agreed that the volume
 level and the mute status are orthogonal.  so 3a) is probably a symptom of
 2), and 3b) is due to the chosen mute icon / text not being updated when
 the slider is moved as the slider should have no effect on the mute
 status.  If I fix 2 do you think this will become a non-issue, or would
 you like the mute status to go to True if the volume slider is set to 0
 and the mute status to go to False if the volume slider is set to anything
 above 0?


 >  4. The volume slider does not respond when the volume keys are pressed
 while the palette is shown.

 4. This is indeed a consequence of the fact we have to poll the mixer
 device to get the volume, since there is no way to get callbacks when the
 mixer's volume is changed.  So we just check the mute status and volume
 level when the palette is popped up and never again.  gnome-volume-applet
 does some crazy poll-slowly-unless-the-user-just-changed-my-slider-then-
 poll-really-fast polling frequency adaptation to mitigate (but not
 obviate) the fact it has to poll the volume, so I don't think there's a
 way around the fundamental problem, but it should be pretty easy to poll
 the volume *when the palette is displayed* if you'd like to improve the
 situation.  The costs are some additional complexity of implementation and
 a (probably trivial) additional amount of CPU (though perhaps we might
 inhibit / interfere with suspend if the user walked away after mousing-
 over the speaker icon, which mightn't be desirable code behavior).



 >
 > I'n my opinion, 1-3 are mandatory fixes.  While 4 is clearly the correct
 behavior in a self-consistent system, I recognize that the signals
 necessary to do it might not be in place at this point.  If there is any
 confusion about the desired behavior for any of these, please assign to
 interface-design.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7248#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system