GNOME Bugzilla – Bug 67649
Patch for UI issues with range widgets
Last modified: 2011-02-04 16:09:21 UTC
I've made a few changes to the range widget. Here are the problems I have with the current system and my changes: 1. The current button-bindings are confusing. In the trough, clicking the middle button jumps the bar to the clicked position. The closer you click to the end of the scrollbar, the closer to the start of end of the document it snaps to. However, clicking the middle button on the stepper (which you would logically expect to snap right to the end) steps in pages instead. Therefore, this patch puts snap-to-end on button-2 on the steppers, to be consistant with the trough behaviour. 2. Scrolling is unresponsive. When I hold down a mouse button on a stepper or in the trough I obviously want to scroll immediately. Instead, the range widget waits an extra long time before doing anything at all (SCROLL_INITIAL_DELAY + SCROLL_LATER_DELAY). Second, when I get to the right position and release the mouse button, the range widget scrolls an extra step so that I overshoot. This patch causes the range to scroll on the initial button press event, then to wait SCROLL_INITIAL_DELAY+SCROLL_LATER_DELAY, then to step every SCROLL_LATER_DELAY. When the button is released, scrolling stops immediately. 3. Common actions are too slow. In the current system, for the steppers, we have: - Step forward: fast (button-1) - Step backward: very slow (move to other end of widget) - Page forward: fast (button-2) - Page backward: very slow (move to other side of thumb/slider) - Snap to end: fast (button-3) - Snap to other end: very slow (move to other end of widget) This patch uses button-3 to reverse the scroll direction in the steppers and in the trough. With this, we have: - Step forward: fast (button-1) - Step backward: fast (button-3) - Page forward: fast (move up a few pixels to the trough) - Page backward: fast (move up a few pixels to the trough) - Snap to end: fast (button-2) - Snap to other end: very slow (move to other end of widget) As you can see, three operations are the same speed, step and page backward are both much faster, and only page forward is slower (and then only slightly). Since stepping backwards and forwards though a document finding the right position is a very common operation, being able to change direction by simply using a different mouse button is very useful. I hope this discussion has been convincing! Also, the patch removes more lines than it adds ;-)
Created attachment 6314 [details] [review] Fixes range widget behaviour, as described above
I agree with Thomas. Using another mouse button to switch the scrolling direction is a BIG time saver. A rather usable littke-known OS does exactly this, and it's very useful.
I've experience with a system that has scroll bars which `reverse' their behaviour when used with an alternate button. E.g. down arrow Btn 1 scrolls down, Btn 3 scrolls up. Not having to move the pointer to the other end of the sometimes long scroll bar is a real boon. Moving to a system without it is *very* noticeable. Another nice thing about this system was that when two scroll bars were controlling the same view, i.e. one panning left/right, the other up/down, dragging a thumb with Btn 1 dragged just that thumb, draggin with Btn 3 dragged both thumbs -- instant `panner' widget!
I would strongly agree with Thomas' assessment of changes needed to the scrollbar behaviour. The current setup is rather confusing when you first start to use gtk packages, and the current other-button actions don't add anything that I find myself using on a day-to-day basis. I have only used Linux for about six months, previously having using mainly RISC OS and some Windows machines, and while the current behaviour is an on Windows behaviour, I find the ability to page up and down simply by using a different mouse button to be hugely useful in just about every application I use on RISC OS. I for one would be very glad to see this (and the panning behaviour mentioned by ralph above) implemented in the future.
http://mail.gnome.org/archives/gtk-devel-list/2001-December/msg00202.html Has this patch broken into a couple of pieces. Putting on the 2.0.0 milestone so we don't forget to apply at least the uncontroversial pieces. (Note that whether we apply the controversial pieces or not will _not_ depend primarily on the number of additional people who add comments to this bug ;-)
Right-click should be reserved for contextual menus. If users come to expect right-click to pop up a contextual menu, it will be very confusing if it does something else in other contexts, such as scroll a document. This is particularly bad because right-click by itself normally does nothing unless the user subsequently selects a menu item, so most users will not be very cautious about right-clicking.
Created attachment 6764 [details] [review] The 'uncontroversial' part of the patch, updated for 1.3.14.
Putting this on the 1.3.15 milestone as suggested on mailing list (no reason to wait, is there?). BTW, if the UI improvements bit isn't going to be applied (and I guess it's too late for that now), could we at least disable button-3 on the scroll arrows? I think everyone agrees that the current behaviour (losing the user's place in the document) is wrong for a button-3 action.
ri Feb 22 20:28:18 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkrange.c: Applied patch from Thomas Leonard to make stepper click to scroll take effect immediately, rather than after a delay (#67649). * gtk/gtkrange.c: Remove right-click == step in trough since it isn't a useful binding and it's a large area to hit accidentally. (Leave it on the steppers since its more useful there and less likely to do accidentally.) I'm going to treat the larger changes as WONTFIX... If you think a modifier to reverse direction would be useful, could you file another bug to track that issue? Thanks, Owen