GNOME Bugzilla – Bug 657194
render_layout() should be able to propagate style classes to pango layouts
Last modified: 2018-05-02 15:11:24 UTC
Gnome-documents implements a custom text cell renderer that, among other things, has this snippet in its ::render() implementation: gtk_style_context_save (context); gtk_style_context_add_class (context, "dim-label"); gtk_render_layout (context, cr, ..., layout); gtk_style_context_restore (context); The "dim-label" style class comes from the theme. This is quite pedestrian. It would be a lot easier to say, layout = pango_make_layout_with_markup ("<div class=\"dim-label\">Look, a dim label</div>"); gtk_render_layout (context, cr, layout); That is, pango layouts should be able to have chunks with explicit style classes, which get resolved to the final styles by gtk_render_layout(). I'm filing this bug against GtkStyleContext because I'm not sure how all the pieces should interact --- whether Pango needs pluggable markup elements, or something.
Pango would need pluggable markup parsing and pluggable attributes support to make that happen. Or said diffferently: Pango would need to gain all the capabilities of a modern web text rendering engine. And of course, you also want :first-letter, :first-line and whatnot pseudo-classes, too. But I'm not seeing this happen anytime soon when looking at the amount of development that goes into Pango these days.
There's quite a gap between 'extensible markup' and 'web text rendering'. I would not approach this in such a maximalist way.
Well, the problem is that the moment you add a new class, you also potentially get a completely new set of styles. So there might not just be a different color, but the font might also change to bold, 20px, underline, suddenly there's a border and the background-image might change to a face of me smiling. While of course you don't need to implement all of this at once, it sounds useful to keep that in mind as a requirement. What one could do if one wanted to do small steps is to extend the internal markup parser used for links to parse some <span class=".."> attribute and add something similar to the links and apply markup from those in the same way we apply markup for links today. But that's tricky because you'd need to apply all the attributes there as you can't compare which ones stay unchanged...
*** Bug 681941 has been marked as a duplicate of this bug. ***
*** Bug 766763 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.
This would definitely be still good to have for Geary. For example, we want to display sender and recipient email addresses with the address part as a dim label: To: Michael Gratton mike@vee.net ^^^^-- this is displayed dim To achieve this at the moment we need to use two GtkLabel instances and a container. That is a pretty suboptimal workaround since it for messages with long recipient lists you may have 100's of widgets instead of 10's, users can't select the whole address at once to copy/paste it all in one go, and it also messes up using ellipses when space constrained, since you have to enable ellipses on both GtkLabel instances, and so you get both truncated, looking like this: To: Micha... mike@v... Rather than this: To: Michael Gratton...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/366.