#4008 closed defect (fixed)
Add toolbar palette that can be locked for touch usage
Reported by: | erikos | Owned by: | erikos |
---|---|---|---|
Priority: | Immediate | Milestone: | |
Component: | Sugar | Version: | 0.97.x |
Severity: | Unspecified | Keywords: | r+, olpc-test-passed |
Cc: | manuq, walter | Distribution/OS: | OLPC |
Bug Status: | Assigned |
Description
Examples are the description Palette and the brush Palette in Paint.
Behaviour: you can hover over it and it goes away automatically and you can lock it and it stays (touch case). This is indicated by the arrow as with the subtoolbars.
Attachments (8)
Change History (24)
Changed 11 years ago by erikos
comment:1 Changed 11 years ago by erikos
- Cc manuq added
- Keywords r? added
Manuel, can you please have a look. Thanks.
comment:2 follow-ups: ↓ 7 ↓ 9 Changed 11 years ago by erikos
Issues with the patch:
- when you move the mouse over the widget and let the Palette start to be popped up and click then the popup stops
- click again and the Palette looks locked moving the mouse out, the Palette does hide
comment:3 Changed 11 years ago by erikos
Another issue is, that the locking is not synced with the sub toolbars in the primary toolbar. There can be more than one item locked.
comment:4 Changed 11 years ago by manuq
Here with Gonzalo we observe the same issue with mouse over, then click. Also we see the "more than one item locked", but this one doesn't seem too bad. The Description palette is locked in the activity subtoolbar.
Other than this, the solution is fine, API and implementation wise. The usage of the arrows like in the subtoolbars is a good idea for consistency.
comment:5 follow-ups: ↓ 6 ↓ 8 Changed 11 years ago by manuq
Maybe the icons in the tray should lock to: #4173 .
comment:6 in reply to: ↑ 5 Changed 11 years ago by godiard
comment:7 in reply to: ↑ 2 Changed 11 years ago by garycmartin
Replying to erikos:
Issues with the patch:
- when you move the mouse over the widget and let the Palette start to be popped up and click then the popup stops
- click again and the Palette looks locked moving the mouse out, the Palette does hide
Testing in Log, this is working very well for the touch case :) The mouse use issues noted above (interaction with mouse over hover state) is indeed a little frustrating, you can be trying to open and have it close on you, then hover stops working for it until you click the icon again, but for the touch use case the behaviour is looking good.
comment:8 in reply to: ↑ 5 ; follow-up: ↓ 10 Changed 11 years ago by garycmartin
Replying to manuq:
Maybe the icons in the tray should lock to: #4173 .
I'd not object to that design, but they might be tricky. Arrows would need to be on the top of the icon pointing up to indicate where the palette will be opening (pointing down when open); only one palette should be open at once to avoid confusion and clobbering another nearby device icon palette.
comment:9 in reply to: ↑ 2 Changed 11 years ago by garycmartin
Replying to erikos:
Issues with the patch:
- when you move the mouse over the widget and let the Palette start to be popped up and click then the popup stops
- click again and the Palette looks locked moving the mouse out, the Palette does hide
Note that this 'hover & click stopping the palette from opening' behaviour is also happening on buddy, access-point icons in the neighbourhood/group/home views when using trackpad/mouse interactions. Activity icons don't seem to be an issue as a click there has a primary action, resumes the activity, and the palette is closed.
comment:10 in reply to: ↑ 8 Changed 11 years ago by erikos
Replying to garycmartin:
Replying to manuq:
Maybe the icons in the tray should lock to: #4173 .
I'd not object to that design, but they might be tricky. Arrows would need to be on the top of the icon pointing up to indicate where the palette will be opening (pointing down when open); only one palette should be open at once to avoid confusion and clobbering another nearby device icon palette.
Yes, I skip this for this cycle. Gets too tricky. In the end we have three different Palette behaviours:
- lockable Palettes (once locked no mouse moving interaction can close it anymore, you have to unlock it explicitly)
- Palettes with no primary action (those are toggle-Palettes, clicking on it will reveal/hide the Palette)
- Palettes that have a primary action (clicking on the icon will do a defined primary action)
comment:11 Changed 11 years ago by erikos
One small case that does not work 100% properly:
- hello world test case
- open the activity subtoolbar
- click on the colorbutton
---> the activity subtoolbar should close
Changed 11 years ago by erikos
New patch that (finally) handles as well the points raised in the ticket
Changed 11 years ago by erikos
New patch that (finally) handles as well the points raised in the ticket
Changed 11 years ago by erikos
Patch for Abacus to the new lockable button for the custom abacus Palette
comment:12 Changed 11 years ago by erikos
- Cc walter added
@Walter, attached is a Patch from Gonzalo for Abacus to use the new lockable button for the custom abacus Palette.
@manuq: attached is a follow up patch for the toolkit.
comment:13 Changed 11 years ago by erikos
- Keywords r+ olpc-test-pending added; r? removed
- Resolution set to fixed
- Status changed from new to closed
Pushed follow up patch for the toolkit. Abacus is handled in #4260
comment:14 Changed 11 years ago by greenfeld
- Keywords olpc-test-passed added; olpc-test-pending removed
There are lockable palettes in 13.1.0 os20/Sugar 0.98.
comment:15 Changed 10 years ago by dnarvaez
- Component changed from sugar-toolkit-gtk3 to Sugar
Add support for locking Palettes