Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#4173 closed defect (incomplete)

Adjusting sliders via touch in Speaker or Speech frame device dismisses the palette

Reported by: garycmartin Owned by: erikos
Priority: High Milestone:
Component: Sugar Version: 0.97.x
Severity: Major Keywords: 13.1.0
Cc: garycmartin Distribution/OS: Unspecified
Bug Status: Assigned

Description

Trying to adjust the Sliders found in the Speaker and Speech device palettes via touch will dismiss the palette once you start to move the slider. There is a very short delay and then the palette closes while you're still trying to touch drag the slider. If you are very quick you can move the slider a little before it closes.

Tested this is only an issue for touch screen interaction, the trackpad cursor works as expected – though the Volume device is very slow/laggy (on both XO-1.75 and XO-4) and doesn't remember settings on an XO-4, but these are different issues. Easier to test on the Speech device sliders due to the Volume bugs.

Attachments (4)

frame_lock_arrows.png (9.4 KB) - added by erikos 8 years ago.
frame device lock arrows
frame_lock_palette.png (18.7 KB) - added by erikos 8 years ago.
frame device lock Palette
0001-Lockable-Palettes-add-support-to-draw-the-arrow-at-t.patch (3.0 KB) - added by erikos 8 years ago.
Lockable Palettes: add support to draw the arrow at the bottom/top of the icon
0001-Frame-make-the-speech-and-speaker-device-Palette-loc.patch (1.8 KB) - added by erikos 8 years ago.
Frame: make the speech and speaker device Palette lockable

Download all attachments as: .zip

Change History (12)

comment:1 Changed 8 years ago by manuq

Related: #4008 .

Changed 8 years ago by erikos

frame device lock arrows

Changed 8 years ago by erikos

frame device lock Palette

comment:2 follow-up: Changed 8 years ago by erikos

  • Cc garycmartin added

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?

comment:3 Changed 8 years ago by erikos

Quick changes I did for testing.

diff --git a/extensions/deviceicon/speaker.py b/extensions/deviceicon/speaker.py
index c541675..329a8a7 100644
--- a/extensions/deviceicon/speaker.py
+++ b/extensions/deviceicon/speaker.py
@@ -48,6 +48,7 @@ class DeviceView(TrayIcon):
 
         self.set_palette_invoker(FrameWidgetInvoker(self))
         self.palette_invoker.props.toggle_palette = True
+        self.palette_invoker.props.lock_palette = True
 
         self._model = DeviceModel()
         self._model.connect('notify::level', self.__speaker_status_changed_cb)
diff --git a/extensions/deviceicon/speech.py b/extensions/deviceicon/speech.py
index 79b50a6..7122331 100644
--- a/extensions/deviceicon/speech.py
+++ b/extensions/deviceicon/speech.py
@@ -47,6 +47,7 @@ class SpeechDeviceView(TrayIcon):
         TrayIcon.__init__(self, icon_name=_ICON_NAME, xo_color=self._color)
         self.set_palette_invoker(FrameWidgetInvoker(self))
         self.palette_invoker.props.toggle_palette = True
+        self.palette_invoker.props.lock_palette = True
 
         self._manager = speech.get_speech_manager()
diff --git a/src/sugar3/graphics/palettewindow.py b/src/sugar3/graphics/palettewindow.py
index 7063681..28218e2 100644
--- a/src/sugar3/graphics/palettewindow.py
+++ b/src/sugar3/graphics/palettewindow.py
@@ -1198,14 +1198,14 @@ class WidgetInvoker(Invoker):
             return False
         alloc = widget.get_allocation()
         arrow_size = style.TOOLBAR_ARROW_SIZE / 2
-        y = alloc.height - arrow_size
+        y = alloc.y
         x = (alloc.width - arrow_size) / 2
         context = widget.get_style_context()
         context.add_class('toolitem')
         if self.locked:
-            Gtk.render_arrow(context, cr, 0, x, y, arrow_size)
-        else:
             Gtk.render_arrow(context, cr, math.pi, x, y, arrow_size)
+        else:
+            Gtk.render_arrow(context, cr, 0, x, y, arrow_size)

The arrow drawing we would need to make dependent on where the icon is (toolbar or frame), or add an option.

comment:4 Changed 8 years ago by erikos

  • Bug Status changed from Unconfirmed to Assigned
  • Priority changed from Unspecified by Maintainer to High
  • Severity changed from Unspecified to Major

Changed 8 years ago by erikos

Lockable Palettes: add support to draw the arrow at the bottom/top of the icon

Changed 8 years ago by erikos

Frame: make the speech and speaker device Palette lockable

comment:5 in reply to: ↑ 2 ; follow-up: Changed 8 years ago by garycmartin

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

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

comment:6 in reply to: ↑ 5 Changed 8 years ago by erikos

Replying to garycmartin:

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

comment:7 Changed 8 years ago by dnarvaez

  • Resolution set to incomplete
  • Status changed from new to closed

No design agreement. Should be discussed again on the mailing list before we can think of implementing anything.

comment:8 Changed 7 years ago by dnarvaez

  • Milestone 0.98 deleted

Milestone 0.98 deleted

Note: See TracTickets for help on using tickets.