GNOME Bugzilla – Bug 563688
GtkScale (GtkRange) should jump to clicked position
Last modified: 2013-01-18 21:18:10 UTC
It would be nice if GtkScale supported jumping directly to the position the user clicks, that is instead of moving the number of steps towards the desired position. This feature is actually used on mobile devices.
Created attachment 124165 [details] [review] Introduce "relative-steps" I implemented the new property "relative-steps". If it is set to FALSE, a single click has the same effect as currently middle click. The key difference is however that touchscreen devices usually have only a normal click.
I'd be more sympathetic if this would use gtk-touchscreen-mode rather than adding yet another knob.
Created attachment 124799 [details] [review] Introduce jump-to-position I improved the patch a little with suggestions from Mitch, and renamed the property "jump-to-position", which seems to be a much better name. I don't see how this behaviour would be related to touch screens.
You mentioned touch screens yourself. It doesn't make much sense to me to add this as a random behaviour-changing property.
(In reply to comment #4) > You mentioned touch screens yourself. It doesn't make much sense to me to add > this as a random behaviour-changing property. Oops, bad wording on my side. What I actually meant was, it is not specific to touch screens. Granted, my use case is about a touch screen. Yet it would make perfect sense even on a workstation and in fact it would be just as useful on a mobile device to let it move relatively. As an alternative, I could imagine a GtkSettings value, since to me it's clearly about platform behaviour. However I am not sure if it makes sense that all sub classes should adapt then, ie. whether scrollbars should also jump. And I don't think e.g GtkScale could easily implement the feature as opposed to GtkRange.
Created attachment 142409 [details] [review] Only implement the jump-to-position property I stripped the patch down to the property and no functions and added a note that it should be used in subclasses of GtkRange. So whenever the behaviour is desirable, a subclass can enable it easily. This avoids the question of subclasses, ie we want it in scales but not in scrollbars.
The patch still compiles. Any chance for an opinion on the updated patch?
Middle click is not discoverable and a slider shouldn't be necessary consistent with scrollbars. All sliders on the web use left click to jump. Please accept this patch!
Also see bug 137812.
Created attachment 209908 [details] [review] Make GtkScale jump to clicked position instead of stepping Attached is a slightly modified version of Christian's patch. It works with current gtk+ master and sets 'jump-to-position' to default for GtkScales. The topic of making scrollbars behave the same was brought up in irc, but I don't know what the final decision was. If they should behave the same, 'jump-to-position' could be set to default unconditionally. Also, we might want to think about leaving the stepping behavior for windows builds, as that is how sliders typically behave on windows. How is conditionally enabling such a feature for a platform usually handled?
@Lars, GNOME designers clearly expressed the desire to change the behavior of the scrollbars at the same time. So that Slider and Scrollbars behave in the same way.
The same way being jumping on left-click.
Created attachment 209910 [details] [review] Make GtkRange jump to clicked position instead of stepping Thanks for the clarification, Christian. I've updated the patch to make 'jump-to-position' be the default.
(In reply to comment #13) > Created an attachment (id=209910) [details] [review] > Make GtkRange jump to clicked position instead of stepping > > Thanks for the clarification, Christian. I've updated the patch to make > 'jump-to-position' be the default. Just tried this out and, in general, I really like the behavior. There is one thing that feels pretty odd though. It doesn't seem to differentiate between clicks on the handle of a scrollbar or unmarked (round handle in Adwaita) range widget and the trough. So, it results in the scroll view or scale selection jumping suddenly as I reach for the drag handle.
Created attachment 212912 [details] [review] Change button bindings for range widgets around It seems to be general consensus that button 1 should do the jumping, so we now jump to the clicked position on primary button clicks and page on secondary button clicks. Touch behaves like primary.
Created attachment 212916 [details] [review] Add a 'fine adjustment' mode to ranges Shift-click in the slider now starts a drag in 'fine adjustment' mode, where we move the slider 10-times slower than the mouse. This can be very helpful when scrolling through a very long document or webpage, and moving the scrollbar even a single pixel already jumps too far in the content.
Created attachment 212924 [details] [review] better patch
Pushed this for now.
for the record: when this change suddenly showed up on my system's scrollbars (not sure why it only popped up now), I found this disconcerting and not any kind of improvement. I can live with retraining myself to right click on all my scrollbars, but that's what I'm going to do, and it is an inconvenience to me, not an improvement. ajax says much the same.