Re: Patch for UI issues with range widgets

[Owen Taylor <otaylor redhat com>]

Thomas Leonard <tal00r ecs soton ac uk> writes:

> Hi, I've made a few changes to the range widget. Here are the problems I have
> with the current system and my changes (there are no API 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.

I really think there is very little "logic" that is going to make
sense here to people beyond the button 1 actions. It's basically
pretty much arbitrary.

Since middle button actions are not easily available for many
people, so I'd be hesitant to move the fairly important "jump
to end" action onto it. 

(I think Windows does "jump to end" on right button click on the
stepper, though I'd have to check to be sure.)
 
Relevant bug numbers are:

 http://bugzilla.gnome.org/show_bug.cgi?id=63735
 http://bugzilla.gnome.org/show_bug.cgi?id=59600

In the first Calum suggests that we probably should make right button
in the trough do jump-to-here, since that's a useful action, and
people not used to Xt/Motif probably won't find it on middle
button, even if they have a middle button.

> 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.

This change sounds reasonable. Can you submit it as a separate patch?

> 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 guess this just seems like a random reassignment of button actions
to me... yes it does give you fast reverse actions, but at the
expense of moving important actions onto middle click.

If you want fast reverse actions, I'd suggest going to the NeXT style
button placement (can be done in a few lines in your .gtkrc), or
possibly we should add a modifier to reverse the actions of all clicks
in the scrollbars.

Regards,
                                        Owen