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 321056 - GtkRange: render arrows insensitive when in end position
GtkRange: render arrows insensitive when in end position
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.8.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-11-09 12:34 UTC by Michael Natterer
Modified: 2005-11-25 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch against HEAD implementing the above (2.22 KB, patch)
2005-11-09 12:35 UTC, Michael Natterer
committed Details | Review
Patch as comitted to HEAD (14.37 KB, patch)
2005-11-11 12:50 UTC, Michael Natterer
committed Details | Review

Description Michael Natterer 2005-11-09 12:34:25 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).
Comment 1 Michael Natterer 2005-11-09 12:35:44 UTC
Created attachment 54532 [details] [review]
Patch against HEAD implementing the above
Comment 2 Tim Janik 2005-11-09 15:33:34 UTC
thanks, comitted.
i'm lazy, so please try to include a changelog entry in the future (that also
gets you better crediting ;)
Comment 3 Matthias Clasen 2005-11-09 21:19:07 UTC
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).
Comment 4 Jody Goldberg 2005-11-09 22:07:09 UTC
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.
Comment 5 Tim Janik 2005-11-10 13:23:07 UTC
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.
Comment 6 Jody Goldberg 2005-11-10 14:23:26 UTC
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.
Comment 7 Tim Janik 2005-11-10 16:48:53 UTC
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.
Comment 8 Jody Goldberg 2005-11-10 17:17:15 UTC
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 ?
Comment 9 Tim Janik 2005-11-10 17:41:41 UTC
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.
Comment 10 Jody Goldberg 2005-11-10 17:51:01 UTC
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.
Comment 11 Michael Natterer 2005-11-11 12:49:38 UTC
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.
Comment 12 Michael Natterer 2005-11-11 12:50:39 UTC
Created attachment 54632 [details] [review]
Patch as comitted to HEAD
Comment 13 Tim Janik 2005-11-11 14:13:17 UTC
patch looks good, thanks mitch.
resolving as fixed again.
Comment 14 Billy Biggs 2005-11-11 14:34:07 UTC
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?
Comment 15 Tim Janik 2005-11-11 14:46:24 UTC
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.
Comment 16 Billy Biggs 2005-11-11 14:55:38 UTC
Introducing a bug into applications until they support a new API seems like
an API break to me.
Comment 17 Owen Taylor 2005-11-25 12:36:13 UTC
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.