GNOME Bugzilla – Bug 722438
Scrolling: be able to disable the zoom/precise mode
Last modified: 2018-05-02 15:55:18 UTC
I don't like the scrolling zoom mode, it is not how I use the scrollbar. When I want to skim through the content to find quickly what I'm searching, I do that in several steps: 1. click on the scrollbar, and hold the button pressed. 2. look at the content, perhaps reading the section titles. 3. scroll to find the section I want to read. The problem: during step 2, the scrollbar often goes into zoom mode, so step 3 doesn't work. The workaround is to directly move the scrollbar just after we click on it, so the zoom mode is disabled. But this is not convenient. And for me the zoom mode is useless, if I need to scroll a small distance, I use the mouse scroll wheel. I think the zoom mode is not a good idea. It should at least be possible to disable it.
I agree. This behavior should really be toggleable, just like gtk-primary-button-warps-slider is. Zoom mode is extremely unintuitive for me and constantly gets in the way of what I'm trying to do.
I have to support this bug report being a gtk user since 10 years. It took me a long time to finally find the cause of this behaviour. I was blaming ubuntu first (overlay remainings) and later searched the web for keywords like scrollbar, gtk, slow, weird, bug. Now I know it's a feature. My suggestion: 1. Remove the time-triggered zooming feature. 2. Make the new zoom-mode the default for right-click action There are maybe not many supporters here, but most normal users will not find this bug report...
*** This bug has been marked as a duplicate of bug 728739 ***
I move this bug to gnome-tweak-tool, since the GTK+ devs don't care. There is a workaround described there: https://bugzilla.gnome.org/show_bug.cgi?id=728739#c9 It would be nice to have a setting directly in gnome-tweak-tool for that.
Hi, I've created a small Tk/Python script that allows this setting to be changed via a simple GUI: https://gitorious.org/gtk-scrollfix/gtk-scrollfix Hopefully some people might find this useful until the gnome-tweak-tool adds support for it.
(In reply to comment #4) > I move this bug to gnome-tweak-tool, since the GTK+ devs don't care. It is not true that GTK+ developers don't care. There's 3000 open GTK+ bugs, and not all of them are easy. > There is a workaround described there: > https://bugzilla.gnome.org/show_bug.cgi?id=728739#c9 > > It would be nice to have a setting directly in gnome-tweak-tool for that. This 'workaround' affects not just the scrolling zoom mode, but every use of long presses in GTK+.
I agree that there needs to be a way to disable the zoom mode of scrolling. I often unintentionally trigger zoom mode when viewing the scrollback in a terminal when I get a long stack trace, with the results that I can't view the whole thing without re-clicking and losing my place. Very annoying.
(In reply to Sébastien Wilmet from comment #0) > The workaround is to directly move the scrollbar just after we click on it, > so the zoom mode is disabled. But this is not convenient. This does only disable the zoom mode if the scrollbar gets moved far enough. If it gets moved only a few pixel the zoom mode can still trigger. But I'm not sure if this is a bug or a feature. (In reply to Sébastien Wilmet from comment #4) > I move this bug to gnome-tweak-tool, since the GTK+ devs don't care. If this issue is more related to GTK+ than gnome-tweak-tool I recommend to change the product back to gtk+ as otherwise it could delay a potential fix even more. Also I'm affected by this issue if I'm programming something which hits productivity a bit. Personally I would like an option to en/disable this feature too but I also think that the zoom mode needs a better mechanism to trigger as it could be a really useful feature.
Re-assigning back to GTK+.
I also ran into the problem of triggering scrolling zoom mode unintentionally. I use a pen tablet instead of a mouse, so lacking a scrollwheel I'm dependent on dragging the scrollbar for all my scrolling. One would say that zoom mode would help here, but in practice it only hinders my scrolling when I want to slow scroll through a file to read it. At least having a gtk setting for disabling zoom mode would be good, even if there is no GUI for setting it?
Is there a place to file more "systematic" bugs like user feedback not being taken into account?
30 USD for whoever fixes this. Copy and paste the issue URL into Bountysource's search.
For me it's now triggered by pressing shift at the start of a drag instead of by a long press, but I haven't noticed this issue for a long time (since the delay was made longer some time ago). I'm using 3.22 in Debian, but I can't find a relevant entry in either the Debian or upstream changelog. Shift seems like a more usable trigger to me, but it does have its own problems for any ambitions about running GTK on phones etc.
Trying to make things like this universal among different physical platforms has been tried (by Microsoft) and it didn't work out too well. In my own case, increasing gtk-long-press-time in ~/.config/gtk-3.0/settings.ini to 4000 disables the feature completely, not sure how. No matter how long I hold it in for (way over 4 seconds), it doesn't budge. I don't know what other programs or widgets use the long-press feature, so I don't know whether it breaks anything else. However, I can still use it if I press shift and then click. That's satisfactory, and if more apps used GTK-greater-than-2 (whatever the correct terminology is now), I would probably use it sometimes (like scrolling through long terminal output). It seems I'm also using Debian's libgtk-3-0 version 3.22.1-1.
(In reply to burritobazooka+gnome from comment #14) > In my own case, increasing gtk-long-press-time in > ~/.config/gtk-3.0/settings.ini to 4000 disables the feature completely, not > sure how. Oops, I completely forgot I'd done that too, except in my case it's 3000. This seems to be about 6s, so it appears that the units are 2ms instead of 1ms. So maybe not disabled in your case, just much longer than you thought?
(In reply to Tony Houghton from comment #15) > > Oops, I completely forgot I'd done that too, except in my case it's 3000. > This seems to be about 6s, so it appears that the units are 2ms instead of > 1ms. So maybe not disabled in your case, just much longer than you thought? Yep, that's indeed what happened. How unintuitive.
Eventually the 2ms per unit is just another bug and needs to be reported.
Edit: On thinking about it maybe gtk-long-press-time can be enhanced for an unlimited time as a simple way to disable this feature (for example with the value -1) so users can still rely on using shift to explicitly enable this feature if they want.
As stated previously in this thread, setting gtk-long-press-time is a non-solution to this bug as it would also affect every other widget which long-press (though I don't know of any that I have actually used). All we need is an option like gtk-enable-zoom-scroll and/or gtk-enable-auto-scroll
In that case maybe the suggested option to disable this feature should not disable it if the user explicitly enables it with shift.
The zoom/fine-tune behaviour comes from GtkRange, and even if this could be grafted onto Scroll(bar|edWindow) only, inevitably people would want it for GtkScale et al too, so moving. (In reply to burritobazooka+gnome from comment #11) > Is there a place to file more "systematic" bugs like user feedback not being > taken into account? Please, start by not assuming bad intentions everywhere... User feedback is great, but resources aren't infinite, and again: (In reply to Matthias Clasen from comment #6) > (In reply to comment #4) > > I move this bug to gnome-tweak-tool, since the GTK+ devs don't care. > > It is not true that GTK+ developers don't care. There's 3000 open GTK+ bugs, > and not all of them are easy.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/462.