GNOME Bugzilla – Bug 321056
GtkRange: render arrows insensitive when in end position
Last modified: 2005-11-25 12:36:13 UTC
There is a patch in maemo-gtk that changes GtkRange to render its arrows insensitive when the adjustment is in its min or max position. I think this is a very useful and intuitive change, esp. since GtkSpinButton already does this for its arrows. (maemo adds a style property for that, the patch attached here does this unconditionally because it's IMHO always the right thing to do).
Created attachment 54532 [details] [review] Patch against HEAD implementing the above
thanks, comitted. i'm lazy, so please try to include a changelog entry in the future (that also gets you better crediting ;)
In the meeting today it appeared as if we need a way to turn this off for individual widgets (and maybe a setting to turn it off globally).
As discussed in the meeting today gnumeric uses the adjust-value signal to allow a user to scroll past the current boundaries of the scrollbar either via the arrows or by dragging the scrollbar. Assuming we need to retain compatibility I'd suggest two things 1) auto desensitize the arrows at the boundaries only if there are no adjust-value signal handlers. 2) provide api for apps to densitize the arrows of a widget (per instance not global) manually. That seems like it will be backwards compatible for any app that cares.
jody, i think you meant the GtkRange::adjust-bounds signal. changing behaviour based on the number of handlers on this signal is too magic and it doesn't catch chanegs in the class' default handler. so i agree with jody's (2), we need per-instance and even per-arrow API as explained during the meeting: http://www.gtk.org/plan/meetings/20051109.txt e.g. something like: typedef enum { GTK_SENSITIVITY_AUTO, GTK_SENSITIVITY_ON, GTK_SENSITIVITY_OFF, } GtkSensitivityType; void gtk_range_set_arrow_sensitivity (GtkRange*, GtkArrowType, GtkSensitivityType); GtkSensitivityType gtk_range_get_arrow_sensitivity (GtkRange*, GtkArrowType); with the sensitivity defaulting to _AUTO. _ON is the old behaviour, and _OFF is needed for applications like gnumeric which have to decide on the sensitivity on their own.
tim : I was suggesting (1) && (2) If we set the default to AUTO backwards compatibility will have changed. Old applications which do not know about the new flag will not work against the new library.
jody, (1) is simply not acceptable API wise. and please note that mitch's patch only changed the way the arrows are drawn, so "not work" is a bit exaggerating.
tim : I understand that (1) is a kludge. Could you clarify what the patch does ? Are you saying that it only draws the arrows insensitively, but still accepts events on them ?
yes. the patch only affects the "sensitivity" used by the paint function and it does that in accordance to adjustment->value + page_size >= upper. so no event processing is affected here.
Then I withdraw my 'not work' comment in #6. It will only look wrong but it will still work. Although I'd appreciate a comment to that effect in the source with a link here so that future developers do not change that. Other than that your proposed api looks good if it can be called from the adjust-bounds signal.
Ok, added per-stepper API (including properties) to configure the behavior with the enum values mentioned above: 2005-11-11 Michael Natterer <mitch@imendio.com> Added per-stepper API for GtkRange's stepper sensitivity as discussed in bug #321056: * gtk/gtkenums.h: added GtkSensitivityType which can be { AUTO, ON, OFF }. * gtk/gtkrange.[ch]: added properties "lower-stepper-sensitivity" and "upper-stepper-sensitivity" and public getters/setters for them. Changed stepper drawing to honor the new properties. * gtk/gtk.symbols: added the new symbols.
Created attachment 54632 [details] [review] Patch as comitted to HEAD
patch looks good, thanks mitch. resolving as fixed again.
Just a comment, it seems like a really bad idea to draw buttons which you can click on in some applications appear insensitive, but still honour the clicks. Can this be an opt-in feature rather than opt-out?
billy, the button is drawn insensitively precisely because pressing it if the slider is at the end would make no sense/wouldn't have any effect. for those applications that still react to button events in these situations by means of custom hooks, the new API was added to allow them to reflect this in the drawn arrow sensitivity. so the scenario you describe can only occour as a temporary bug in the arrow visibility until the application is properly ported to the new API, if at all (it really depends on how those specialized apps update their bounds). not enabling sensitivity adaptions in the genral case because of that would affect more than 99% of the scrollbars out there though and thus render this feature mostly useless.
Introducing a bug into applications until they support a new API seems like an API break to me.
Definitely an incompatible API break in my opinion. We added API to enable what gnumeric does explicitely. It's not a fringe use case. Turning around and misdrawing that unless you call *more* new API doesn't seem compatible to me.