Scrollbars are hard to get right. They have very small click targets and are barely usable to make fine adjustments. In GTK+ 3, we’ve made a number of changes to scrollbars in the last few years.
- We’ve removed the steppers
- We made the scrollbar smaller and look more like an indicator
- Clicking outside the thumb jumps to the position; paging is still available via right click
In particular the last change caused some heartburn. To compensate, we added a ‘zoom mode’, which scrolls slowly (1-1 correspondence between pointer movements and scroll delta). Unfortunately, it turned out to be too much of an easter egg. To trigger it, you have to hold down Shift while clicking on the thumb. The combined use of mouse and keyboard is also complicated for many users.
This cycle, we’re trying again to make scrolling useful. I’ve just merged patches by Jon McCann and Jakub Steiner to change the zoom mode is triggered. Click-and-hold or long press on the slider will now put the scrollbar into zoom mode. We’ve also added a visible feedback for this, which makes a big difference. To top it off, Jon added autoscroll – if you are scrolling in zoom mode and move the pointer above or below the widget, the scrolling will continue until you let go of the button. This turns out to be very nice. You should try it once GTK+ 3.9.12 is out.
Since the autoscroll is hard to capture in a screenshot, I’ve also made a little video to show it off.
I was wondering what the heck was going on with my scroll bars. Not only are they tiny now, they are also completely unusable.
I am glad that you found the usage also cryptic enough to warrant a blog post, I was worried about me being the only one.
So, has the jump-to-position-when-clicking-outside-the-thumb mistake been fixed, in this new version?
What about clicking on the middle scroll button to scroll left-right-up-down, similar to the behavior in MS Windows? I have always liked that functionality
I appreciate all the thoughts and work you put into this, and I don’t want to sound negative, but this really breaks how I interact with scrollbars.
When I want to scroll a large distance, what I often do is:
– Find the thumb, press and hold the mouse button.
– Look back to the content, decide where I want to go
– Move up or down, looking at the content, till I find the correct position.
With the change, the scrollbar will probably go into zoom mode, which is pretty much the opposite of what I’m trying to achive. If I need to scroll slowly, I’ll use the scroll wheel, or for more control the scroll buttons (which are unfortunately gone).
Any chance this is going to be a user or theme setting?
Agreed… this sounds like zoom mode is something that will regularly be triggered by accident. If I click and hold on the slider, it’s because I want to drag the slider… not because I want to activate some secret scrolling mode…
:/ Click and hold is the only way I scroll since that’s the only overlapping behaviour between GTK and firefox atm..
I’ve never felt the need for any zoom scrolling.. (where is that stolen from btw?), but maybe I didn’t know I need it š
Awesome changes!
However, according to the video, the autoscrolling is waay too slow. (havent tried it myself)
Iām not really sure how you can sensibly combine those two, but for autoscroll, the delta between handle and mouse position should determine the speed, so the further i move the mouse, the faster it should go.
I have tried this using gnome-ostree tool and it feels quite good. I didn’t know about the zoom function, this is an interesting solution how to make it easier to find. The graphical indicator is very welcome. But if I move the cursor above/below the widget, the scrolling continues very slow, just a single line per second or so. Maybe it could speed up a bit if I move the cursor further from the widget / apply more pressure at the screen edge?
The use case for the slow autoscroll is tied to fine control. Large lists like exposed by Evolution are impossible to navigate line by line and fine mode avoids the need for steppers while autoscroll avoids needing to reposition the cursor over the slider.
Sorry, but I think even Ubuntu’s overlay scrollbars are saner than this.
I’d have to agree, and I don’t even like Unity. I like GNOME 3, despite all of its quirks and oddities, but this is the kind of thing that leaves even the staunchest GNOME or GTK fans slapping their foreheads… How to properly scroll a window in a graphical toolkit should not still be an issue for developers in 2013.
I’m beginning to see why Unity was ported to Qt, even Canonical is starting to catch on.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
Sometimes I want to cry.
Why on earth change this from the Gnome 2 behaviour? (Guess what – I’m still using Gnome 2). Of course, it’s open source and a voluntary project – people can work on what they like but is this really important in growing usage of Gnome? Not at all – not in my opinion. The growth is in tablets, and this is an opportunity which is being left behind.
By the way, there has to be a place for feedback even if it’s ignored.(Yes I know what you’ll say – if that’s what’s important to you – join the project and start addressing this concern).
Just tried it and it worked great: http://build.gnome.org/ostree/buildmaster/images/current/
On Fedora 19 (Gnome 3.8 with GTK 3.8.2) I just tested left-clicking and right-clicking the scrollbar trough for a mix of applications: Firefox, GEdit, Evince, Eclipse, and Adobe Reader.
They were all consistent, except for Firefox, which is by far my most used application.
Somehow we need to get Firefox to conform to the system’s scrollbar behavior.
https://bugzilla.mozilla.org/show_bug.cgi?id=803633
Very nice!
Eager to test as soon as possible š