After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 94376 - Fine-grained user control over GtkRange value
Fine-grained user control over GtkRange value
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.0.x
Other All
: Normal enhancement
: Small feature
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-09-27 17:51 UTC by a.guru
Modified: 2013-02-13 04:09 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
patch for gtk+-2 (6.86 KB, patch)
2002-09-27 17:53 UTC, a.guru
needs-work Details | Review

Description a.guru 2002-09-27 17:51:07 UTC
The patch below brings additional behavior to GtkRange objects (i.e.,
GtkHScale, GtkVScale, GtkHScrollbar, and GtkVScrollbar).  This happens
when their slider is either dragged with mouse button 1, or warped then
dragged with mouse button 2.  The original behavior is exactly the same
as long the mouse pointer is kept within the range's trough or slider.
The additional behavior is invoked by moving the mouse pointer laterally
outside these regions.  The more so, the more control over the range's
value becomes fine-grained.  This is especially useful when viewing
large documents where dragging a conventional scrollbar just one pixel
down already produces too much movement (i.e., change in range value).
The change in behavior is smooth and intuitive and respects availability
of the traditional behavior for the user's usual interaction.

This is offered as a "damping" style property for the range, with three
choices:  none, linear, or exponential.

The main ideas behind the patch are that

        1) This interaction with the range fundamentally aims to modify
        its value, rather than move its slider.  (Thus the change in
        the struct itself, for recording the initial state.  Also,
        notice how this cleans up the gtk_range_button_press() function.)

        2) The value's precision may be much better (smaller than 1,
        numerically) than what corresponds to a 1-pixel move of the
        slider.  The state of the range is recorded by its high-precision
        value, not by its rendering on the display (i.e., the slider's
        position).

        3) This specific interaction with the range (dragging) aims to
        _modify_ the range's value _relative to_ its former self, rather
        than to just set a completely recalculated value from its lower
        precision rendering on the display.  (Thus the new
        delta_coord_to_value() function.)

(Maybe other interactions with the range could be modified to respect the
same principles and affect the value; this remains to be investigated.)

The testgtk program's "range controls" popup has been modified to show
10 decimal digits right of the decimal point on its GtkHScale, instead
of just one, so that the effect of the patch can be seen.  Observe how
the 0-to-100 value can now be changed in the thousandths rather than
just in the tenths by using either the GtkHScale or the GtkHScrollbar
on the popup (with "linear" damping, or even better with "exponential"
damping).

The patch below is for gtk+-2.  If there is interest, I also have a
back-ported patch for gtk+-1 that achieves mostly the same behavior
as linear damping.

I believe the code is clean and respects the surrounding coding style.
Comment 1 a.guru 2002-09-27 17:53:08 UTC
Created attachment 11284 [details] [review]
patch for gtk+-2
Comment 2 Owen Taylor 2002-09-27 18:34:00 UTC
It's an interesting idea, and I could see how such a control 
could be useful in dealing with huge amounts of data,
but, on the other hand:

 - I suspect that it would be quit confusing for new users,
   since it breaks the intuitive "the distance you move
   the mouse is the distance that the scrollbar moves"
 - I don't think it should look like a standard scrollbar
   or scale.
 - I think it would be very premature to put it in GTK+
   at this point without experience with the feature
   in real world applications. (User testing)

I'm going to leave this bug open on the future milestone,
but I think the issues above would have to be addressed
before putting it in GTK+, even as an optional feature
that an application could turn on.

Comment 3 a.guru 2002-09-27 18:50:33 UTC
To facilitate user testing, one option could be to apply the patch
with GTK_DAMPING_NONE given as the default to the
gtk_widget_class_install_style_property() function call.
This way, only a change to the gtkrc file would be required to test
the feature.