GNOME Bugzilla – Bug 732915
button: better treatment for autorepeat
Last modified: 2018-04-15 00:11:34 UTC
There are several places where we manually implement auto-repeat when a button (or button-like widget) is clicked and held: GtkScaleButton +/-, gtknotebook scroll arrows, gtkscrollbar steppers. It would be nice to treat this more uniformly, and preserve the button styling as much as possible while doing so. Currently, the scale button +/- buttons don't show proper press/release feedback, because we override the button-press/release handling.
Created attachment 280180 [details] [review] proof of concept: GtkGestureTimedPress This is a simple gesture that emits ::tick signals at regular intervals while the GtkGestureSingle is active (ie. touch/button is pressed)
In many places, we have two intervals, a longer initial timeout, followed by a shorter repeat timeout. Do you think this should be part of the gesture, or should the users simple reset the interval themselves ?
*** Bug 661622 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > In many places, we have two intervals, a longer initial timeout, followed by a > shorter repeat timeout. Do you think this should be part of the gesture, or > should the users simple reset the interval themselves ? IMO setting the interval is simple enough, and allows for doing this on other parameters than just timing (eg. distance or positional based). One place I'm thinking could be useful is on GtkTextView text selection, right now it only reacts to motions, even if you pull the selection so it causes scrolling. OTOH... in many of those places probably what is desired is a change in the step size, and not the frequency, I'm thinking about GtkSpinButton, or even my example above. I guess this is another point in favor to keep the secondary timeout out of the gesture code.
ok, fine with me. Do you have a follow-up patch to use this gesture somewhere ?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new