[Bugs] #4173 sugar HIGH: Adjusting sliders via touch in Speaker or Speech frame device dismisses the palette

[Sugar Labs Bugs]

#4173: Adjusting sliders via touch in Speaker or Speech frame device dismisses the
palette
----------------------------+-----------------------------------------------
    Reporter:  garycmartin  |          Owner:  erikos  
        Type:  defect       |         Status:  new     
    Priority:  High         |      Milestone:  0.98    
   Component:  sugar        |        Version:  0.97.x  
    Severity:  Major        |       Keywords:  13.1.0  
Distribution:  Unspecified  |   Status_field:  Assigned
----------------------------+-----------------------------------------------

Comment(by erikos):

 Replying to [comment:5 garycmartin]:
 > Replying to [comment:2 erikos]:
 > > Hi Gary,
 > >
 > > I said I would not do this, this cycle. But giving it a quick shot,
 the code seems there already.
 >
 > ;)
 >
 > > There are two Palettes in the frame device section that need the
 Palette to be lockable, the Speech and the Speaker one. When we set the
 invoker property for both they have the lockable Palette behaviour: click
 does lock/unlock, hovering does reveal the Palette but not lock it. The
 state is even linked between the two, if a is locked and I click on b, a
 is unlocked and b is locked.
 > >
 > > Now, the question is, how does this graphically look to you? If we do
 this, should only the two Palettes that need the locking be transformed
 that way?
 >
 > So my initial worry is more about the behaviour differences between
 device palettes than the graphics. I'm uncomfortable with some of them
 behaving differently just because of an implementation issue (some have
 sliders in, some don't), this is pretty random for a user to make any
 sense of. Could we make all device palettes lockable, seems reasonable now
 you have solved the 'only one palette locked open at a time' issue?

 Sure, that is easy enough to do. The problem is, what do we do with the
 other cases (e.g. the buddies in the Frame), they are not lockable, so
 there should be a visible differentiation. I don't like the arrows much,
 and already wondered if we should only show them when the Palette is
 popped up (at least for the Palettes), but then the Sub-palette case.
 Argh, maybe we can quickly chat about it tomorrow...

 > Regarding the graphics, it does feel a little unusual for the frame, I'm
 wondering if the lock behaviour is different enough to really warrant
 showing the graphic for the frame case. Also looking at the screen shots
 (have not tested your patch here yet), the device icons seem pushed
 vertically down in the frame too far, this is probably an outstanding
 theme bug (note that the grey outline of an open palette also goes off the
 bottom of the frame, as does the rounded rect press effect that shows when
 holding the AP icon).

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/4173#comment:6>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system