GNOME Bugzilla – Bug 739763
Overlay scrollbars automatically occur in an X11 environment with mouse pointer
Last modified: 2015-06-30 19:10:17 UTC
An example of this behavior can be found with Glade. o Fire up Glade o Add a new GtkWindow o Add a new GtkGrid to the window o Increase the grid's column count to a high number, say 20 o Add a button in the rightmost column o Now grab the tab on the workspace window (with the label 'window1') and drag it so the window is sufficiently wide, i.e. so the button disappears from the scrolled window viewport Now the far right columns of the grid cannot be accessed anymore, there is no way to horizontally scroll, essentially Glade becomes unusable. The commit message introducing these overlay scrollbars (i.e. commit 4455266c5b23be8173b9c93a4cb576f768fb732d) makes a promise that this overlay behavior will not occur in environments with mouse pointers. "We use traditional scrollbars if we find a mouse or if overlay scrolling has explicitly turned off." Since the detection is mouse pointers seems to be currently unreliable, as I think it is making the mistake of turning on overlay scrollbars with the trackpad on my laptop. I suggest that traditional scrollbars be the default, and the overlay scrollbars only show up when a true touchscreen environment is detected. This approach would favor reliability for existing applications without requiring them to be modified/rebuilt/redistributed to explicitly disable the overlay scrolling.
The commit message is not promising anything regarding 'pointers'. It talks about input devices that get classified as mice by XI2. To make this bug report useful, please provide the output of xinput --list.
Output of xinput --list follows: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ USB2.0 UVC 2M WebCam id=10 [slave keyboard (3)] ↳ Asus WMI hotkeys id=11 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
Same problem: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ Integrated Camera id=9 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)] ↳ ACPI Virtual Keyboard Device id=14 [slave keyboard (3)]
I've pushed an overlay-heuristics branch that changes the heuristics to be based on actual device use.
(In reply to comment #4) > I've pushed an overlay-heuristics branch that changes the heuristics to be > based on actual device use. Hi, Just tried the branch with Glade and my same laptop with trackpad, same xinput --list ... same issues persist though - no was to scroll horizontally, can only scroll vertically with scroll events :-/
the branch doesn't change the classification of touchpads. if you use a mouse or trackpoint, you'll get classic scrollbars with the branch
I've merged Carlos' alternative approach, which does things a little differently. We now always shows indicators while the mouse is over the scrolled window, and go to full scrollbars on proxmimity. This feels much better to me.
*** Bug 742184 has been marked as a duplicate of this bug. ***
I'm sorry to reopen this bug because Carlos's approach really seemed to do the trick, but as I found later, some things are still unusable with this approach. The problem occurs in any scrolled window where right-aligned content is interactive. I have 2, if not more examples of this breakage in Glade. Editing GtkLabel attributes (general tab) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ a.) Start up the dialog for editing attributes b.) Click the 'scale' cell, or any numeric attribute which gets assigned a spin button c.) Try to click the '+' spin button Now the scrollbar is competing with the '+' button of the GtkSpinButton... you find the scrollbar competing with the right aligned content in the scrolled window. The signals with a large signal list where scrolling is needed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ a.) Create a GtkTreeView in Glade (because it has a lot of signals) b.) Navigate to the signals tab c.) Ensure that the height of the property editor is small enough to trigger scrolling (for me it does by default with a large signal list like treeview) d.) Now try to click the devhelp 'book' icon to get documentation on a given signal. If devhelp is not installed/enabled then it would be the 'After' checkbox which occupies the right aligned cell. Again we have a scrollbar competing for clicks with the right aligned content. More annoying still is that the user generally doesnt know what happened, when I originally stumbled on this, someone was asking me about the 'scale' attribute of labels... I tried to click the '+' button and the attribute window just scrolled, I did not even notice the appearing scrollbar the first time, just clicked the '+' button and the window scrolled. Can we please have the window-with-scrollbars be the first class citizen, and the overlay scrollbars only appear when a touchscreen is reliably detected ? This would make much better sense because: o In a touchscreen environment that was not correctly detected, the scrollbars would be visible but the application would still be usable. o When a non-touchscreen environment is not correctly detected, scrollbars go away and we have degredation to a point where things are unusable.
Recently updated Gedit and Evince to 3.16 and noticed that the scrollbars are very thin and hard to hit in but are widened when mouse pointer is moved over them. Even though I only have a mouse and no touchpad. Output of xinput --list: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech USB Laser Mouse id=8 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Logitech USB Keyboard id=9 [slave keyboard (3)] ↳ Logitech USB Keyboard id=10 [slave keyboard (3)]
s/hard to hit in/hard to hit/ Note that this is on my desktop system where I only have a standard USB mouse and no trackpad.
> Recently updated Gedit and Evince to 3.16 and noticed that the scrollbars > are very thin and hard to hit in but are widened when mouse pointer is moved > over them. Even though I only have a mouse and no touchpad. Same here. This commit seems to have removed the "mouse-detection". https://git.gnome.org/browse/gtk+/commit/gtk/gtkscrolledwindow.c?h=gtk-3-16&id=2a3a7306ef1d6be2a1bc167551fc726ee9fb1329 (In reply to Martin Ejdestig from comment #10)
I'm closing this bug, because the current behavior is as intended, and there are opt-outs for both developers and users.
So it is now intended that on a desktop system where only a mouse is available the overlay scrollbars are used? You say opt-out, does this mean there is an option to change back to the classic scrollbars?
(In reply to sworddragon2 from comment #14) > So it is now intended that on a desktop system where only a mouse is > available the overlay scrollbars are used? No. Scrollbars appear on key navigation as well. > You say opt-out, does this mean > there is an option to change back to the classic scrollbars? Application developers can opt to always display scrollbars, using gtk_scrolled_window_set_overlay_scrolling().
Users can set GTK_OVERLAY_SCROLLING=0 in the environment to disable overlay scrollbars
Created attachment 306430 [details] [review] patch to sync documentation with current implementation Here is a patch to update the GTK+ documentation, which was still describing the old behaviour.