Translucent TextViews

Now that we’ve finally rolled 3.0 out of the door… it’s time to hang up our hats and stop adding features to GTK+.

Err, nah forget about that – instead lets add cool stuff for an awesome 3.2 now !

As discussed in bug 636695, using GdkRGBA colors in GtkTextView is just about the last thing blocking us from completely deprecating GdkColor and moving GTK+ to an RGBA only api for colors.

But wait ! Implementing the RGBA color values on GtkTextTag is not a mere api cleanup, it also lets us…

Do stuff with GtkTextView that was not possible before

As you can see, now the foreground, background and paragraph background colors of text in the text view can be painted with translucency to the background of the GtkTextView, this particular demo connects to the “GtkWidget::draw” signal and simply fills in the background with checkers.

Of course most of the time you use a text view with a default solid white background for readable text, however this new feature does open up some…

New Possibilities

As usual, this installment of “GTK+ feature of the week” was brought to you by Openismus GmbH.

Currently the code is available for your compiling pleasure in the rgba-texttags branch.

What follows here is just my own personal brain storm…

Ideas for GTK+ hackers

While going over the GtkTextView code, which we all know is a fearsome animal not to be taken lightly or hunted in plain sight I came up with a bit of an idea of how we could start taming this beast. Text View code is not horrible really, it just hasn’t received much love over the years and needs a little tidying up.

Currently we have these components:

• GtkTextBuffer and friends (GtkTextIter, GtkTextMark, GtkTextChildAnchor, GtkTextTag, GtkTextTagTable): This is all a part of the TextView’s data model, it’s very modular and it all makes sense. Sure, it’s much code but all of that code is well segmented and justified as far as I can see.
• GtkTextBTree, GtkTextLine, GtkTextLineSegment: Some caching on the view side of things, all of this is private and caches things about how to render segments of text from the buffer model into the view, still quite modular code and probably very well thought out and well written.
• GtkTextLayout: The heart of the beast where all the cached data is traversed and prepared for rendering, this is probably where most hackers are scared off… while most if not all of the code in there is well justified and needed, this code could probably be better organized and have more rich comments to guide the hacker who’s looking at this code for the first time.

Now the fun part:

• GtkTextAttributes/GtkTextAppearance: This is something of a customized PangoAttribute the text appearance is a structure holding all the needed attributes for rendering a ‘segment of text’, a segment being a continuous string of glyphs that all share the same attributes… actually the GtkTextAttributes structure holds a GtkTextAppearance member, they could probably be merged into the same structure and the apis which handle this could be better defined (currently we have GtkTextTag modifying the attributes manually with exposed struct members and the like).
• GtkTextRenderer (found in gtktextdisplay.c): This is the really fun part, this jem is actually a derived PangoRenderer class and takes over the actual rendering of the glyphs (the fact this jem already existed is why it was relatively easy enough to add RGBA rendering of the pango glyphs into the mix)… The GtkTextRenderer object inspects the custom GtkTextAttributes and uses these extended PangoAttributes to render the glyphs.

Now without digging into the ultra-complex innards of GtkTextLayout, I thought it would be a sweet idea to give GtkTextRenderer and GtkTextAttributes a bit more air time… these are for the most part internals of GTK+ and would not become part of the public api but… we could use the GtkTextRenderer to render text in GtkLabel and GtkEntry (and possibly elsewhere).

By working a little bit towards fine tuning the GtkTextRenderer and attributes to have a sane internal API and reusing it, we would already be able to render text from GtkLabel and GtkEntry using RGBA text attributes… at a relatively low cost. Also, a move in this direction would help demystify the text view code somewhat (at least hackers would be more familiar with GtkTextAttributes and GtkTextRenderer and would not have to consider those entities while looking at the rest of the huge code that is GtkTextView).

Anyway, just some food for thought for anyone who might be interested.