GNOME Bugzilla – Bug 316712
gtkentry initial rendering bug w/ scroll_offset
Last modified: 2006-03-08 14:46:19 UTC
When a GtkEntry is first created, it will have a scroll_offset of 3 (the initial dummy allocation.width minus 2 * INNER_BORDER, negated). Under some circumstances (that I can't find a simple test case for), it will actually render the text with this scroll_offset, and then re-render it immediately afterward with a scroll_offset of 0 when the allocation is set to its correct value, causing the text to jump 3 pixels. This patch fixes the initial setting of scroll_offset. Index: gtk/gtkentry.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkentry.c,v retrieving revision 1.284.2.1 diff -u -r1.284.2.1 gtkentry.c --- gtk/gtkentry.c 2 Sep 2005 19:51:06 -0000 1.284.2.1 +++ gtk/gtkentry.c 19 Sep 2005 15:42:16 -0000 @@ -3419,6 +3419,8 @@ gdk_drawable_get_size (entry->text_area, &text_area_width, NULL); text_area_width -= 2 * INNER_BORDER; + if (text_area_width < 0) + text_area_width = 0; layout = gtk_entry_ensure_layout (entry, TRUE); line = pango_layout_get_lines (layout)->data;
i know i've seen this as well, in particular when entries were used for temporary editing context such as in a canvas. unfortunately i don't have a test case handy either. the above patch still does make sense to me, the drawable width shouldn't ever be negative, and the width shrunken by INNER_BORDER still shouldn't be negative.
Fixed in HEAD: 2006-03-08 Michael Natterer <mitch@imendio.com> * gtk/gtkentry.c (gtk_entry_adjust_scroll): make sure that the text_area_width is always >= 0. Fixes bug #316712 (Dan Winship).
applied to gtk-2-8 as well.