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

the new 'testtextview' demo found in gtk+/tests

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

TextView rendering translucent text over a downscaled image of Iguazu falls.

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.

4 Responses to “Translucent TextViews”

  1. Simon says:

    Of course, those screenshots *are* a good demonstration of why being able to do something doesn’t mean it’s a good idea. But it’s good that the toolkit can support it.

  2. tvb says:

    @Simon: Right, use cases for this should be very specific.

    It would be more useful… in colorful kiosk environments for instance,
    if at least the text can have an outline color and/or a dropshadow color
    and dropshadow angle/offset etc… (solid white or black outlines on
    translucent large text in colorful scenarios can stand out very clearly
    while still producing a pleasing effect).

  3. dbdoskey says:

    How about actually having better support in GtkTextView (and the model) for implementing these two use cases without any hacks (currently not possible):
    1. having a split view by sharing the same model with two views
    2. having a document ‘changer’ by having one view and changing models

    I think the biggest mistake of the model/view design (tree* also suffers from similar problems) in gtk is that the state is split across the model and the view in, sometimes, not so sane ways. If you also had a GtkTextState which held where the cursor was positioned, and what text was highlighted, where the scroll was to, etc… then you could implement the above 2 cases and more like this:
    1. having a different state for each view, allowing them to share the model
    2. keeping a state for each model and changing the state with each model
    3. for saving/loading a text file and wanting it to be in the exact same way just save and load the state,
    etc…

    The state could also hold more things from the treeview: which items are folded, size of the columns after resizing, etc..

    This is I believe the biggest thing holding back the model/view design in gtk, but it is quite offtopic for you post,

    sorry

  4. Name (required) says:

    I guess https://bugzilla.gnome.org/show_bug.cgi?id=425651 is also related to this. :)