It is triggered after a timeout, if you press and don't move

Thanks. Just me being a bit silly then. I realise this feature can be useful, but I find it a bit annoying at the moment. Is there a way to do any of the following (in order of preference):

Increase the timeout.

Only activate the feature with shift, not with a timeout.

Disable it altogether.

Please consider this an enhancement request for at least one of the above to be made configurable, or at least make the hard-coded timeout longer if you're against adding settings.

*** Bug 709596 has been marked as a duplicate of this bug. ***

*** Bug 722438 has been marked as a duplicate of this bug. ***

*** Bug 734055 has been marked as a duplicate of this bug. ***

*** Bug 735677 has been marked as a duplicate of this bug. ***

*** Bug 736828 has been marked as a duplicate of this bug. ***

*** Bug 731800 has been marked as a duplicate of this bug. ***

The gtk_gesture_long_press in gtkrange.c is responsible for this bug. Perhaps there should be a way to reduce the distance the pointer can travel before the gesture is cancelled, or to increase timeout before the gesture is emitted.

In gtkgesturelongpress.c the timeout (delay) is set by:

  g_object_get (gtk_widget_get_settings (widget),
		"gtk-long-press-time", &delay, NULL);

so if anyone wants a workaround, you can add

[Settings]
gtk-long-press-time = 5000

to ~/.config/gtk-3.0/settings.ini

to change the timeout to 5 seconds.

Since my bug (#736828) is marked as duplicate of this bug, I'll add some details here:
Not only zoom mode is activated while there is some movement, but when it is triggered, it cancels the movement which is already happened, which is much much worse than undesired enabling of zoom mode itself. I might be able to live with undesired change, but not when the contents jump back to the initial position of scroll bar. (Actually, IMHO this is a separate bug and it should not have been marked as duplicate of this one. My bug was not about when this mode is triggered, but about what happens after triggering this mode).

I usually trigger it for gnome-terminal with a long scrollback.

* Scroll up by a few pixels
* Notice that it scrolls way to fast due to long scroll back
* Adjust and scroll down again to the point wanted
* Zoom mode kicks in and resets me back to where I started :(

Thanks for the "work-around" with gtk-long-press-time.
I'm using GTK 3.10 so I cannot test this yet.

Anyway, it would be good if it was possible to disable this "zoom mode" completely.
Sorry but I think this feature is more annoying than useful for most users because the behaviour is not intuitive at all.

My use case is the following:
- I open a PDF file in evince for reading.
- I grab the scrollbar to slowly move down first but potentially quickly jump further in the document later on (while keeping the mouse button pressed).

This does not work with the zoom mode, because once scrolling slowly it prevents the user from scrolling faster later.
Thus the maximum scroll position is limited by the screen size.

Moreover, this behaviour is inconsistent with every other GUI toolkit (that I know of), and leads to different scroll bar behaviour even on the same desktop.

The automatical activation of the zoom mode is very annoying. 

Isn't everybody using the mouse wheel to fine-scroll? Why exactly is this automatical activation of the zoom mode better?

I never want to use the zoom mode. Please allow disabling it.

See bug #722438 for adding a setting to gnome-tweak-tool.

Created attachment 297612 [details] [review]
range: set initial position to current position when enabling zoom

This is a fix for the scrollbar jumping back when zoom mode gets activated as mentioned in comment 10. Please be extra cautious when reviewing since this is just a patch I hacked together quickly when this was mentioned on IRC.

Can you try if this works just the same ? I can't really reproduce the 'jumping' problem, so I can't test this myself.


diff --git a/gtk/gtkrange.c b/gtk/gtkrange.c
index 404dc3a..bd95ee9 100644
--- a/gtk/gtkrange.c
+++ b/gtk/gtkrange.c
@@ -2437,7 +2437,12 @@ gtk_range_long_press_gesture_pressed (GtkGestureLongPress *gesture,
                                       gdouble              y,
                                       GtkRange            *range)
 {
-  update_zoom_state (range, TRUE);
+  if (!range->priv->zoom)
+    {
+      /* unset initial position so it can be calculated */
+      range->priv->slide_initial_slider_position = -1;
+      update_zoom_state (range, TRUE);
+    }
 }
 
 static void

That's actually what my first attempt at fixing this looked like, too. When that didn't work I tried to copy what gtk_range_multipress_gesture_pressed to initialize the positions.

I think I'll declare this fixed for now - the timeout is now twice as long.

Is the "jump" problem also fixed? (The patch was merged?).

yes

*** Bug 728373 has been marked as a duplicate of this bug. ***