GNOME Bugzilla – Bug 137812
the Gtk[H|V]Scale needs a way to disable stepping
Last modified: 2015-05-11 11:06:26 UTC
Currently, when a user clicks on a scale widget, the handle (and value) does not move just under the cursor, where the scale was clicked. This type of behaviour should be made available via a property, and would be used by media players to handle seeking.
The addition would require changes to gtk_range_button_press(), in gtk+/gtk/gtkscale.c. Owen, would such a patch be accepted upstream, or would there be another way of doing this?
We need confirmation from GNOME usability folks that * Having some scales have different click-on-the-trough behavior is right * Having these scales look the same is right Before we proceed here.
Media widgets tend to stretch the use case of normal widgets. I see the usefulness of the behavior being different for scanning vs. the normal scaling, but I think we might do better to have a different widget for this. Perhaps more feedback for where you'd scan to (i.e. with something showing what timeslice you'd scan to or what chapter in the dvd would be more useful*) Maybe it's time to think more about having widgets specifically for media applications. * That's just suggestions off the top of my head
I think I wasn't very clear in my original request, which is why we're getting to this result. The plan isn't for applications to use the Scale widgets directly, with that property (no stepping) turned on. It is to allow the creation of a widget (that would probably have a different look), but would descend from GtkHScale. Without this property, the scale would have to be rewritten from scratch.
As for visuals, it's pretty common for a media player control to have a narrower trough than a regular slider, i.e.: =====[ ]================ rather than ------------------------- | [ ] | ------------------------- so that might be one suggestion for "would probably have a different look". Of course you'd still want the vertical clickable region to remain the same, otherwise it would be pretty fiddly to use.
Am I coming to the right conclusion thinking that I could add this property as long as the property is only used for subclasses the Gtk[H|V]Scale with a different UI?
Why can't you simply add the property to the subclasses then ?
All the logic is in the GtkScale, and it's not possible to override it without basically rewriting the scale widget. Adding this property would be easier, IMO.
Created attachment 38796 [details] [review] gtk-range-no-steps.patch Add a property, and a structure member to track whether we want to warp or step when the user clicks on the trough.
Created attachment 39002 [details] [review] gtk-range-no-steps2.patch Make the click_trough_steps a construct-only property (do we need a new helper constructor for this?), also change the slider to be a round knob (using the off radio button code). Still need to change the slider width code to make it work properly though. Am I on the right track?
Created attachment 39010 [details] [review] gtk-range-no-steps3.patch "Fix" the slider width problem. It's a pretty bad hack though, any hints welcomed.
*** Bug 359721 has been marked as a duplicate of this bug. ***
I just had a quick look at the patch and stumbled over the gtk_paint_option call. From the documentation: "Draws a radio button indicator in the given rectangle on window with the given parameters." I don't think it is sane to use that. A detail string modification would be more appropriate in my oppinion.
(In reply to comment #13) > I just had a quick look at the patch and stumbled over the gtk_paint_option > call. From the documentation: > "Draws a radio button indicator in the given rectangle on window with the given > parameters." > > I don't think it is sane to use that. A detail string modification would be > more appropriate in my oppinion. The GtkRange needs a different look if the behaviour is going to be different. Using the option button is obviously wrong, but it was a way to show what it's supposed to do. I don't want this to be configurable for end users, but rather an option for application writers to have a scale that behaves differently (for media players for example)
(In reply to comment #11) > Created an attachment (id=39010) [edit] > gtk-range-no-steps3.patch > > "Fix" the slider width problem. It's a pretty bad hack though, any hints > welcomed. + + g_object_class_install_property (gobject_class, + PROP_CLICK_TROUGH_STEPS, + g_param_spec_boolean ("click_trough_steps", + P_("Click-trough steps"), + P_("Clicking on the trough moves the slider in steps, rather than warp underneath the mouse"), + TRUE, + G_PARAM_WRITABLE | G_PARAM_CONSTRUCT_ONLY)); Please add a Since tag and don't use tabs in new code. Plus we need accessors for the new value. > I don't want this to be configurable for end users, but rather an option for > application writers to have a scale that behaves differently (for media > players for example) Using a detail doesn't mean it's for end-users only, it is a means for the engine to draw a different widget. A problem might be, though, that current engines won't draw the widget differently since they are not aware of the new detail.
I don't think we should mix behavior (click wraps to the clicked point instead of stepping there) which drawing changes. That sounds to me like one normal property (for the click behavior) plus one style property (for the drawing). The change to gtkscale.c is therefore bogus. Apart from that there are coding style issues: + g_param_spec_boolean ("click_trough_steps", Properties use '-' instead of '_'. + } else { The { and } must be on separate lines. + (event->button == 2 || range->click_trough_steps == FALSE)) || That should be "!boolean" instead of "boolean == FALSE" The header file change is binary incompatible, all new members go to GtkRangeLayout in the .c file. I also fail to see why the property is only writable but not readable.
We've changed the default a few years ago. Scales jump now