Re: Patch for UI issues with range widgets

On Fri, Dec 28, 2001 at 12:17:47PM -0500, Owen Taylor wrote:
> 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):
> 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'd agree that button-2 should have the least useful of the three actions
on it. However, I'd disagree that jump-to-end is more common than reverse.
Please try the patch for a few seconds, you might be convinced ;-)

The point about jump-to-end is that you only do it once, and then you're
stuck there. Reverse scolling is useful continuously while moving though a

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

That would be quite a strong argument for those button assignments :-(
Although, I don't know if enough people are aware of it to make it much of
an issue. If we're going for consistancy with other OS's, then I'd point
out that RISC OS had reverse on button-3, but I think that's the best
place for it anyway...

Whether it's on button-2 or button-3 doesn't bother me too much, though,
as long as reverse is on *some* button.

> Relevant bug numbers are:

This advocates putting the most common secondary action on button-3, but
doesn't consider reverse scrolling when making the decision...

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

This pretty strongly breaks standard Unix usage, though :-(
The second suggestion of using Control for jump-to-here (as well as
button-2) sounds reasonable.

> > 2. Scrolling is unresponsive.
> This change sounds reasonable. Can you submit it as a separate patch?


> > 3. Common actions are too slow.
> 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.

The only way I could see to get reverse scrolling was to have a second
stepper next to the first. But having to move the mouse every time you
want to change the scroll direction means this is a clumsy solution. I
think it comes from systems with only one mouse button.

Anyway, please try the patch for a bit!

Here is the patch for responsiveness:

--- oldrange.c	Thu Dec 27 16:27:48 2001
+++ gtkrange.c	Thu Dec 27 16:55:51 2001
@@ -1271,25 +1271,13 @@
   if (range->layout->grab_button == event->button)
-      GtkScrollType scroll;
       MouseLocation grab_location;
       grab_location = range->layout->grab_location;
-      scroll = range_get_scroll_for_grab (range);
       range_grab_remove (range);
       gtk_range_remove_step_timer (range);
-      /* We only do the move if we're still on top of the button at
-       * release
-       */
-      if (grab_location == range->layout->mouse_location &&
-          scroll != GTK_SCROLL_NONE)
-        {
-          gtk_range_scroll (range, scroll);
-        }
       if (grab_location == MOUSE_SLIDER)
         update_slider_position (range, event->x, event->y);
@@ -2309,6 +2297,8 @@
   range->timer->step = step;
+  gtk_range_scroll (range, range->timer->step);
 static void

Here is the patch for button assignments:

--- oldrange.c	Thu Dec 27 16:27:48 2001
+++ gtkrange.c	Thu Dec 27 16:55:51 2001
@@ -1023,10 +1023,10 @@
           return GTK_SCROLL_STEP_BACKWARD;
         case 2:
-          return GTK_SCROLL_PAGE_BACKWARD;
+          return GTK_SCROLL_START;
         case 3:
-          return GTK_SCROLL_START;
+          return GTK_SCROLL_STEP_FORWARD;
@@ -1040,10 +1040,10 @@
           return GTK_SCROLL_STEP_FORWARD;
         case 2:
-          return GTK_SCROLL_PAGE_FORWARD;
+          return GTK_SCROLL_END;
         case 3:
-          return GTK_SCROLL_END;
+          return GTK_SCROLL_STEP_BACKWARD;
@@ -1054,12 +1054,12 @@
         if (range->trough_click_forward)
             return range->layout->grab_button == 3
             return range->layout->grab_button == 3


Thomas Leonard
tal00r ecs soton ac uk		tal197 users sourceforge net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]