GNOME Bugzilla – Bug 678108
Introduce GtkSpinSelection: a streamlined widget to select an option within a range
Last modified: 2014-09-16 03:53:37 UTC
Created attachment 216423 [details] [review] GtkSpinSelection implementation and minimal test Hey, Currently in order to allow selecting a value within a GtkAdjustment provided range, one has to use either a GtkSpinButton or a GtkScale, in places where keyboard editability doesn't matter (eg. the values are granular enough) and size/touch-friendliness prime, both unfortunately have shortcomings (GtkSpinButton indeed improved a lot in 3.4, it's mostly about the GtkEntry and how much space it takes wrt the tinier touch targets). So I'm attaching a patch to introduce GtkSpinSelection, it's similar in API and spirit to GtkSpinButton, just that it's not keyboard editable (nav keys do obviously work), has bigger targets and allows panning up/down to change the selection. It also has a ::format-value vmethod to override the displayed value. It could be used for clock/calendar selections, also looks like a nice replacement for combobox-as-zoom-control in apps like evince Still in the TODO: - docs - a11y - probably makes sense to have this widget be a GtkOrientable
Created attachment 216424 [details] screenshot to get an idea
Comment on attachment 216423 [details] [review] GtkSpinSelection implementation and minimal test [Patch => setting "patch" flag and correct mimetype]
There's a lot of conceptual ideas I'm not sure about. First of all, GtkAdjustment. For me an adjustment has always represented a continuous range, while this sounds a lot more like selecting 1 out of N different possibilities. In particular, the values aren't even related numerically to each other - like zoom having "fit page size" and similar. Also, I think GtkAdjustment is a terrible API and we should try to get rid of it and not try to write more widgets supporting it. For example, I can't imagine how this widget would use step vs page sizes usefully. Second, to me this just looks like a combobox (or at least an optionmenu). A set of values and one is selected. Granted, the current combobox API encourages opening the list to select a value, but couldn't you just redesign its UI to encourage flipping (o mouse-wheeling) more? In that case, we wouldn't need another widget and could just reuse the combobox. We'd also get working keynav and a11y already for free.
pan up/down have been added to gtkspinbutton now; so maybe this is no longer needed