mtPaint bugfix

I reported on my blog earlier that I cannot save PNG files compressed, only uncompressed.

I reported the bug to the mtPaint mail-list, and got off to a bad start as I referred to feedback that I had seen on an Ubuntu forum as "dumb" -- but it turned out the the advise given on that forum was by Dmitry (the mtPaint maintainer) himself ...oops. Actually, it wasn't his reply specifically that was dumb, I had read lots of other replies to PNG compression related problems while searching with google and was really making a general comment. Besides, I was very tired.

Anyway, we moved on, and Dmitry solved the problem. An excellent bit of detective work. Here are some of Dmitry's emails to me. I'm sure that he won't mind me reproducing these:

> So, there seems to be a problem with how mtPaint is setting up the
> spin box. The spin box works in other applications. Jaunty uses GTK
> version 2.16.0.

Thanks. Now the prime suspect is obvious - Ubuntu people are mad for
packaging a zero point release of GTK+, for these are guaranteed to be
extra buggy. Anything at all could break in such setting, and Patrick
Volkerding would never inflict such misery on us Slackware users. ;-)
It is GTK+ 2.12.9 on my Slackware 12.1, and GTK+ 2.12.12 on the
current Slackware 12.2.

Now it is time for me to test this suspicion - so I'm off to download,
compile, and test GTK+ 2.16.0.
------------------------

The cause for breakage has been identified. See here:
http://svn.gnome.org/viewvc/gtk%2B/tags/GTK_2_14_7/README?view=markup
Specifically, this part:

51 * In the early 2.14.x releases, GtkAdjustment was changed to enforce
52 that values are restricted to the range [lower, upper - page_size].
53 This has always been the documented behaviour, and the recommended
54 practice is to set page_size to 0 when using adjustments for simple
55 scalar values, like in a slider or spin button.
56 Due to the large number of applications that are affected by this
57 change, the behaviour has been reverted to the old behaviour in
58 2.14.3, with an explicit warning that this change will be
59 reintroduced in 2.90.

And now see here:
http://svn.gnome.org/viewvc/gtk%2B?view=revision&revision=21012
And here:
http://svn.gnome.org/viewvc/gtk%2B/tags/GTK_2_16_0/README?annotate=22531

Basically what happened is that the 2.16 branch had been forked off
before the ABI breakage (!), made in commit 21012 above, had been
corrected in GTK+ 2.14.3. So, the 2.16 branch reintroduced the
breakage again.

I'll now make a workaround for this - should not be hard to do - but
this is an obvious GTK+ bug (ABI break) which should be reported as
one, and a violation of a written promise to boot.

And if you're intent on using GTK+ 2.16.x, you're quite likely to get
burned by more instances of the same. GTK+ 2.14.3 or later does at
least print "Gtk-WARNING **: GtkSpinButton: setting an adjustment with
non-zero page size is deprecated"; GTK+ 2.16 does not, as this change
had also been missed.
--------------------------------------------

Attached is the patch fixing the spinbuttons' breakage in mtPaint
under GTK+ 2.16. It was just as easy as I hoped - only two places in
all (the integer and float spinbutton creation wrappers).

BTW, all versions of mtPaint since 0.00 are affected by this GTK+ bug
- the integer spin wrapper is original Mark Tyler's code (and float
wrapper, copied from it). Only, the other spins' upper limit being off
by 10 is not *THAT* evident. :-)

I know when I first started using Jaunty, I was worried that they were using GTK 2.16.0. That did seem risky.

Anyway, I've got the patch and I'll compile the fixed mtPaint. I would like to thank Dmitry for his work on this. I imagine other major apps will also be forced to do a hack as well.

---

Comments

mtpaint patch
Username: BarryK
For the record, here is Dmitry's patch: [code]--- ../src/mygtk.c 2009-04-07 20:14:13.000000000 +0400 +++ mygtk.c 2009-05-01 20:21:20.000000000 +0400 @@ -61,7 +61,7 @@ GtkWidget *add_a_spin( int value, int min, int max ) { - return (spin_new_x(gtk_adjustment_new(value, min, max, 1, 10, 10), 0)); + return (spin_new_x(gtk_adjustment_new(value, min, max, 1, 10, 0), 0)); } GtkWidget *add_a_table( int rows, int columns, int bord, GtkWidget *box ) @@ -477,7 +477,7 @@ GtkWidget *add_float_spin(double value, double min, double max) { - return (spin_new_x(gtk_adjustment_new(value, min, max, 1, 10, 10), 2)); + return (spin_new_x(gtk_adjustment_new(value, min, max, 1, 10, 0), 2)); } /* void handler(GtkAdjustment *adjustment, gpointer user_data); */[/code]

re: mtpaint bug
Username: BarryK
"Dmitry has emailedme an update on this: [i]The above problem was one manifestation of a bug present in GTK+ 2.16.0 and 2.16.1 (and previously, in GTK+ 2.14.0 - 2.14.2). The bug is promised to be fixed in GTK+ 2.16.2: http://bugzilla.gnome.org/show_bug.cgi?id=581190 For those who have to use an affected version of GTK+, next versions of mtPaint will use a workaround for this bug.[/i] So, I think that I might compile gtk 2.16.2 for jaunty when it is released.

Tags: woof