GNOME Bugzilla – Bug 763741
Wavy/squiggly underline not properly removed
Last modified: 2018-04-15 00:15:36 UTC
1. Have a GtkTextTag with the 'underline' property set to PANGO_UNDERLINE_ERROR. 2. Apply the tag to some visible text. 3. Remove the tag. -> the wavy/squiggly underline is not properly removed, there are some remaining red dots at the bottom. The redraw seems to be one pixel too short on the vertical side. See attachment 156044 [details] for a screenshot.
Bug #103662 is related, see Owen's comment: https://bugzilla.gnome.org/show_bug.cgi?id=103662#c12
Created attachment 324086 [details] [review] Benjamin's patch
Created attachment 324106 [details] [review] textview: Track differences between ink and logical rects This way, we can ensure that we queue redraws on the full ink rect. This is particularly visible for squiggly underlines in spell checking.
Review of attachment 324106 [details] [review]: With the patch applied, I can still see the bug in gedit.
Review of attachment 324106 [details] [review]: ::: gtk/gtktextbtree.c @@ +2656,3 @@ ld = _gtk_text_line_get_data (end_line, view->view_id); if (ld) + end_y += ld->height + ld->bottom_ink; Don't you need a top_ink here as well ?
Created attachment 324121 [details] [review] textview: Track differences between ink and logical rects This way, we can ensure that we queue redraws on the full ink rect. This is particularly visible for squiggly underlines in spell checking.
Created attachment 324123 [details] [review] gtk-demo: Improve markup demo Add squiggly underlines and background, and make the markup editable.
Review of attachment 324123 [details] [review]: ::: demos/gtk-demo/markup.c @@ +30,3 @@ + buffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW (view)); + gtk_text_buffer_get_start_iter (buffer, &start); + gtk_text_buffer_insert_markup (buffer, &start, markup, -1); Need to clear the buffer first, here @@ +97,3 @@ + gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (sw), + GTK_POLICY_NEVER, + GTK_POLICY_AUTOMATIC); Should allow horizontal scrolling
Review of attachment 324121 [details] [review]: .
Attachment 324121 [details] pushed as 45dfdbc - textview: Track differences between ink and logical rects Attachment 324123 [details] pushed as 73fe852 - gtk-demo: Improve markup demo
Some commits have been pushed, but the bug is not fully fixed. If I recall correctly the discussion on IRC with Company, words with some specific letters still trigger the bug.
Does anyone have a usable example of that?
I doubt the problem has been fixed by itself, at least in GTK+ 3.
What I meant was that the description in Comment 11 seems too vague for anyone else to understand/investigate, so unless you or Benjamin have a fix in mind, other readers probably need specific steps to replicate it.
More testing is needed, but I recall correctly that after Benjamin's patches have been pushed, the problem was still not fixed entirely because I still had the bug in gedit with gspell. Since then I've modified gspell to insert a PANGO_UNDERLINE_SINGLE instead of PANGO_UNDERLINE_ERROR to workaround the bug (it's not that bad because Android also has a single underline, although thicker).
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new