GNOME Bugzilla – Bug 133263
proposal for a new GtkRange signal: slider-moved
Last modified: 2011-02-04 16:17:01 UTC
I'm using GTK scrollbars to implement an AWT Scrollbar peer in libgcj, but I've run into a difference in how adjustment events are treated in the two toolkits. An AWT AdjustmentEvent carries information about the type of adjustment that occurred, one of BLOCK_DECREMENT, BLOCK_INCREMENT, TRACK, UNIT_DECREMENT, UNIT_INCREMENT. Currently GtkRange doesn't provide information about how an adjustment happened. It simply updates its GtkAdjustment with the new value that resulted from a user's interaction with the range. I propose a new "slider-moved" signal that will report how a user is interacting with the range, whether they are clicking on a stepper or the trough, or dragging the slider.
Created attachment 24010 [details] [review] implementation of proposed slider-moved signal
2004-02-02 Thomas Fitzsimmons <fitzsim@redhat.com> * gtk/gtkrange.c (gtk_range_class_init): Add "slider-moved" signal. (gtk_range_internal_set_value): Add GtkScrollType parameter. Emit the slider-moved signal when the range's value changes. (update_slider_position, gtk_range_scroll_event, step_back, step_forward, page_back, page_forward, scroll_begin, scroll_end): Update calls to gtk_range_internal_set_value to include a GtkScrollType argument. * gtk/gtkrange.h (struct _GtkRangeClass): Declare slider_moved function. Patch attached. Comments?
*** Bug 93147 has been marked as a duplicate of this bug. ***
If we are going to add something here, maybe it should be more flexible. Say, a gboolean GtkRange::change-value (GtkRange *range, GtkScrollType scroll, gdouble new_value); (TRUE==handled, like events) new_value would be principally meaningful for GTK_SCROLL_JUMP, but would be set to the *unclamped* new value in all cases. Then the default handler does most of the work currently in gtk_range_internal_set_value(). The biggest question mark for me would be interaction with rounding to a certain number of digits and update policy, since gtk_range_internal_set_value() doesn't just call gtk_range_set_value(). It might be fine to ignore that and say that if you override ::change-value and do something different then: a) You are on your own for handling clamping to digits b) Delayed update policies aren't possible The alternative probably would involve renaming and making public gtk_ranger_internal_set_value() but I think that's far too confusing.
Think we should definitely do something here for 2.6.
Created attachment 29888 [details] [review] updated patch to add change_value signal
I've posted an updated patch that implements the signal Owen described. To support delayed update policies can't we just expose the bits that gtk_range_internal_set_value uses? From what I can see, that would mean making both gtk_range_reset_update_timer and GtkRange's update_pending field public.
I'd rather not allow delayed update policies than make gtk_range_reset_update_timer/update_pending public. If people complain we can do something later.
Created attachment 30627 [details] [review] patch to add GtkRange::change-value signal
New patch attached that adds API documentation.
Thu Aug 26 22:44:12 2004 Matthias Clasen <maclas@gmx.de> Provide information about how an adjustment change in a range widget happened. Add a "slider-moved" signal which reports how a user is interacting with the range, whether they are clicking on a stepper or the trough, or dragging the slider. (#133263, Thomas Fitzsimmons) * gtk/gtkmarshalers.list: Add signal type BOOLEAN:ENUM,DOUBLE. * gtk/gtkrange.c (gtk_range_class_init): Add "change-value" signal. (gtk_range_internal_set_value): Rename to gtk_range_real_change_value. Add GtkScrollType parameter. Emit the change-value signal when the range's value changes. (update_slider_position, gtk_range_scroll_event, step_back, step_forward, page_back, page_forward, scroll_begin, scroll_end): Change gtk_range_internal_set_value to gtk_range_real_change_value. * gtk/gtkrange.h (struct _GtkRangeClass): Declare change_value function.
What version of GTK the signal "GtkRange::"change-value" was added ? GTK 2.4.10 does not have it and in the GTK 2.5.3 release notes says signal "slider-moved" was added. Am I missing something ?
I changed the signal name from "slider-moved" to "change-value" before the patch was committed. The ChangeLog entry is incorrect, it seems, and the release notes were probably generated from it. So "change-value" is the signal you are looking for and it is present in gtkrange.c on CVS HEAD.
I've corrected the NEWS and ChangeLog entries.