GNOME Bugzilla – Bug 699915
Selection pattern design updates
Last modified: 2014-08-27 14:22:13 UTC
There's been a round of changes to the selection pattern; these are intended to overcome a bunch of issues that we've encountered with the existing design. Details of the updated design can be found here: https://live.gnome.org/GnomeOS/Design/Whiteboards/SelectionPattern
Sorry for taking so long to answer. I looked at the wiki page, but I did not see what specific changes are requested here. In particular, we already support rubberbanding, using the latest revision of GdMainView, and that's what I see changed from earlier patterns. In any case, first we need a GdMainView (or EggFlowBox) supporting the pattern in libgd or even better in gtk+.
Hey Giovanni! I've added some notes to the wiki page which describe how it changes from the existing selection pattern. Do we have bugs for the Gtk/libgd issues that you mention? It would be good to be able to track those as we move towards the latest iteration of the selection mode.
Ok, there was a lot of stuff I hadn't noticed and required changed in gnome-weather. I now implemented the following points: * Use a standard toolbar at the bottom rather than an overlaid toolbar * Label action items with strings rather than icons * Use a "Cancel" button in the toolbar rather than "Done" * Close selection mode once an action is performed (rather than leaving it open) The remaining one: * Additional ways to activate selection mode (ctrl+click, long press, rubberband selection, etc) needs to be tackled in libgd, but seems to be mostly fine already.
Ctrl+click and rubberband selection should already work in current libgd. eg., look at Documents. I don't know about long press. Is it supposed to be a touch thing? Regarding shift+click, the design says: "shift+click allows ranges of items to be selected". Is that somehow different from the way ctrl+click works at the moment? Or should ctrl+click and shift+click work indentically?
The usual distinction between Ctrl-click and Shift-click is that Ctrl lets you add and remove individual items from the current selection, whereas Shift always adds the range between the selection start and the clicked item. How the 'selection start' point gets updated as you interact with the selection varies and can be a bit confusing.
(In reply to comment #6) > The usual distinction between Ctrl-click and Shift-click is that Ctrl lets you > add and remove individual items from the current selection, whereas Shift > always adds the range between the selection start and the clicked item. Yes, but that distinction gets blurry due to the way the current selection pattern works: (1) The rubberband selection is started with ctrl+click/drag, which is sort of what we think shift+click should do. (2) You can go ctrl+clicking or right clicking individual items to get them selected. Or am I missing something?
I think this no longer needs to be on the blocker list; the bulk of it is done
The new design does not have a selection mode, closing.