Revert GtkAdjustment clamping change?

[Colin Watson]

I was lucky enough to notice this changelog entry during an upgrade:

gnome-system-tools (2.22.0-1ubuntu2) intrepid; urgency=low

  * GtkAdjustment behaviour has changed to restrict the range of the values.
    From the GTK README:
      GtkAdjustment now enforces 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.
    This change meant that the time couldn't be set to greater than 13:49:49,
    as the upper was 23:59:59 and the page_sizes 10:10:10.
    debian/patches/91_time_admin_adjustment.patch corrects this by reducing
    the page_sizes to 0, as recommended in the above quote.
    - http://bugzilla.gnome.org/show_bug.cgi?id=551740

 -- James Westby <james.westby at canonical.com>  Thu, 11 Sep 2008 00:18:54 +0100

Thanks to James for the excellently clear changelog entry! The same
problem turned out to be responsible for a small collection of very
serious bugs in Ubiquity's manual partitioner (see the referenced LP bug
and its duplicates):

ubiquity (1.9.15) intrepid; urgency=low

  * GTK frontend:
    - Don't set page_size in GtkAdjustments; as of GTK+ 2.14 it causes the
      value to be clamped to upper - page_size (LP: #264599).

 -- Colin Watson <cjwatson at ubuntu.com>  Wed, 17 Sep 2008 03:06:59 +0100

As I just pointed out in the upstream bug (although it's on
gnome-system-tools rather than GTK+), the documentation of this
behaviour is *not* clear; the only place I could find where it's
actually documented as described in the release notes is in the source
code, and the HTML documentation almost outright contradicts it. Thus I
expect that many applications will have problems with this. Milosz
Derezynski already pointed out a couple in the upstream bug, and I can
confirm that at least our Inkscape package currently suffers from a
similar problem.

So, two questions:

 * Could somebody do a source code scan of the Ubuntu archive (at least
   main) to try to find instances of this problem? Searching for
   "page_size" (possibly only in files also containing "Adjustment", if
   the former alone produces too many false positives) should be good
   enough to assemble a hit-list to check by hand.

 * Could we please revert this change in our GTK+ packaging for the
   meantime, at least until we get an idea of the scale of the problem?

-- 
Colin Watson                                       [cjwatson at ubuntu.com]