GNOME Bugzilla – Bug 699060
[PATCH] cellrenderertext: Fix possible overwriting of markup
Last modified: 2018-04-15 00:02:59 UTC
Created attachment 242676 [details] [review] cellrenderertext: Fix possible overwriting of markup When creating the layout, attributes were inserted after existing attributes with a matching start_index; this could result in some attributes from markup being ignored/overwritten. For example, if the markup started with a span setting a color, it would be overwritten by the foreground property for that section. Inserting attributes before will ensure markup attributes are preserved.
Created attachment 257358 [details] [review] cellrenderertext: Fix possible overwriting of markup Updated patch.
I confirm the bug. The patch still applies to the master branch and works fine for me. The bug occurs in the completion system of GtkSourceView. We use the :font-desc property to apply the same font as the GtkTextView, and we use the :markup property. When the markup text contains something like "<b>Completion provider header</b>", the bold markup is not applied. With the above patch the text is correctly in bold. The bug doesn't occur when the markup is not applied to the whole text, so for example "blah <b>foobar</b>" is not affected. To test the bug, you can launch tests/test-completion in GtkSourceView. Type something in the GtkTextView -> the completion proposals are shown with the headers "Fixed Provider" and "Random Provider". Those headers should be in bold.
Review of attachment 257358 [details] [review]: Small review, but take it with a grain of salt since I'm not a GTK+ developer. ::: gtk/gtkcellrenderertext.c @@ +1578,3 @@ attr->end_index = G_MAXINT; + pango_attr_list_insert_before (attr_list, attr); I guess a comment here to explain why insert_before() is needed would be useful, so it isn't lost in the git history.
Hmm, I'm not entirely convinced. The attribute handling code should probably be rewritten to be more similar to the corresponding code in GtkLabel
*** Bug 755968 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
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