GNOME Bugzilla – Bug 546754
2.13.6 update create rendering issue in the evolution composer
Last modified: 2008-09-18 07:31:08 UTC
the evolution mail composer has rendering issues when using gtk 2.13.6 (the text is displayed duplicated in a second column, the textview area is wrong when opening the composer, etc), when resizing the dialog everything is correctly displayed again so that seems a refreshing issue, using gtk 2.13.5 there is no such issues
See also bug #546587
Closing as a dupe. This is beginning to look more like a GTK+ or possibly a Metacity issue. *** This bug has been marked as a duplicate of 546587 ***
reopening since the other bug is not against gtk, will close whichever is on the wrong component
This is caused by 2008-08-05 Michael Natterer <mitch@imendio.com> * gtk/gtkadjustment.c (gtk_adjustment_set_value): clamp the value to [lower...upper-page_size] instead of only [lower...upper]. * README: add note about this change. While this fix is correct and should have been there forever, it has the potential to break some corner cases, however these cases would set page_size to a value != 0 which suggests they want it honored.
Matthias, does it mean that every single app should set non-negative, greater than zero value for the page_size, otherwise users will see the behaviour described above?
GtkHtml's GtkLayout page sizes get set in gtk_html_private_calc_scrollbars(), based on the HTMLEngine's calculated height and width, which may be incorrect. The code in gtk_html_size_request() looks awfully suspicious for the "writing" case. And of course there's no comments explaining the reasoning. If the GtkAdjustment change is here to stay then this bug can probably be reassigned to GtkHtml.
Milan: no, setting page_size to zero is perfectly fine and supported, if you don't want paged behaviour. Matthew: it would be great to know in some more detail how GtkHtml is (ab)using adjustments to cause this.
I'm seeing this too.
Behdad: where do you see it? Also in GtkHTML?
Yes, in Evolution's composer. I see up to three copies of the widget, or maybe four, in a 2 by 2 grid.
(In reply to comment #7) > Matthew: it would be great to know in some more detail how GtkHtml is (ab)using > adjustments to cause this. Working on that. GtkHtml only uses GtkAdjustments directly in a few places and I don't see anything overtly fishy going on. Will continue digging.
GtkHtml is a GtkLayout which handles the adjustments all by itself. The adjustments' page_size should always be the width/height of the widget, and not set based on its content. It seems as if GtkLayout does it all correctly and there should be some code removed from gtkhtml.c Also, gtkhtml.c pokes values into the adjustments and never emits the "changed" signal.
Shouldn't the CLAMP() expression be using modulus instead of subtraction? It's giving bad results when (upper < page_size) or (upper > page_size * 2). (I think that's only /part/ of the problem. GtkHtml still needs fixing.)
Fixed in SVN: 2008-08-11 Michael Natterer <mitch@imendio.com> Bug 546754 – 2.13.6 update create rendering issue in the evolution composer * gtk/gtkadjustment.c: instead of CLAMP(), use value = MIN (value, upper - page_size); value = MAX (value, lower); so we don't end up below lower if upper - page_size is smaller than lower.
hmm, bug seems to be still present when applying SVN fix to gtk 2.13.6
the svn change on 2.13.6 works fine for me and an ubuntu user confirmed it fixes the bug too
my bad, I didn't grab the correct patch (git mirror is lagging). sorry for the false alarm
*** Bug 548773 has been marked as a duplicate of this bug. ***
*** Bug 546587 has been marked as a duplicate of this bug. ***