GNOME Bugzilla – Bug 619474
Fixes for GtkAdjustment for GTK+ 3
Last modified: 2012-08-26 13:34:23 UTC
A couple of fixes: * In the early 2.14.x releases, GtkAdjustment was changed to enforce that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. Due to the large number of applications that are affected by this change, the behaviour has been reverted to the old behaviour in 2.14.3, with an explicit warning that this change will be reintroduced in 2.90. * gtk_adjustment_changed() and gtk_adjustment_value_changed() functions. They are used to emit GtkAdjustment::changed and GtkAdjustment::value-changed signals respectively after direct modification of GtkAdjustment's fields. Since all of the public fields of GtkAdjustment are GSEALed now, those two functions are redundant now and should probably be marked as deprecated in GTK+-2.22 and removed from GTK+-3. This was reported by Tadej Borovšak here: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00085.html
Created attachment 161822 [details] [review] Enforce that values are restricted to the range [lower, upper - page_size] This patch reverts the Mathias previous commit to enforce that values are restricted to the range [lower, upper - page_size]
Comment on attachment 161822 [details] [review] Enforce that values are restricted to the range [lower, upper - page_size] Yeah, we should probably do that now.
I'm working on a more complete overhaul of the GtkAdjustment that would hopefully make it a bit more useful. I'm currently having some troubles getting stuff to compile, but once I overcome them, I'll file a bug and link to this one for reference.
Comment on attachment 161822 [details] [review] Enforce that values are restricted to the range [lower, upper - page_size] commit b18b33ae8234982dcc4e694358cbcbc32c3e7e3a
This bug should probably be marked as fixed, since API docs and code are in sync now.
(In reply to comment #5) > This bug should probably be marked as fixed, since API docs and code are in > sync now. What about bug #619493 ?