#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 Eben):

 Replying to [comment:1 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

 Is the string passed accurate?  Maybe there is an off-by-one or some
 rounding error?

 > >  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

 I wish I could discover some causality for this, since it only happens
 about half the time.  I imagine it should be relatively easy to debug,
 though.

 >
 > >  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?

 Hmmm, I do remember that discussion.  After toying with it, though, I
 think what I really want is a unidirectional association.  That is,
 toggling mute on/off should have absolutely no effect on the volume.
 However, I think that explicitly adjusting the volume (either by adjusting
 the slider, or pressing the volume keys) should always un-mute the
 speakers.

 Note that this does not create any correspondence between mute and vol-
 lvl-0.  If the state is (muted, vol-lvl-50) and I slide the slider to 0, I
 wind up in (un-muted, vol-lvl-0).  I think that's the orthogonality I
 meant to convey before.

 (I'm open to argument against this, of course...I recognize that if it
 were a checkbox instead of a menu item I would find it odd to uncheck the
 box automatically.  But I also find that my expectation given the current
 design is that any explicit change in volume should result in an un-muted
 state.)

 >
 > >  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).

 Yeah.  Hold off on this one for now.  It sounds ugly, and it's certainly
 an edge case.

 >
 > >
 > > 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:2>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system