Re: CellRenderText properties question.

[Sven Neumann <sven gimp org>]

Hi,

"Carl B. Constantine" <duckwing duckwing ca> writes:

> However, I can't really find any code examples of how to do anything
> suggested in these docs. For example, I have a GtkTextView that only
> has a single column in it. When I click a button in my window, I
> want to find out the current selection in that TreeView and set it's
> text to Red or Bold or something. I can't seem to find anything that
> shows how to get the exact cell and then change its attributes. I
> can do it globably for a column (and have for testing) but not on a
> single cell.

the API reference is not exactly the place where you'd look for code
examples. The gtk-demo as found in the demos directory of the GTK+
source tree seems like a good place to look for such examples.

> These docs seem to imply that I need some further data in my cell
> model to apply an attribute to. So, it seems like I have to have an
> extra invisible column in my model that holds text attributes,
> update the column text with a new string (say to "red" from "black"
> in order for the text in the visible column to have the attribute
> change. This seems very confusing to me. The docs say "based on data
> in the model" but it's not clear what that means, if it's actual
> attributes stored in the model, or just change based on a
> programmatic condition (col 1 is true so set text to bold).
> 
> How can I change attributes on a single cell without having extra
> data in my model or do I really need the extra data in my model? I'm
> sure I'm missing something obvious but the docs are confusing. Also,
> storing extra attribute data in my ListStore adds memory overhead.

of course you need the extra data. You want to display additional
information, where should it come from if not from the model? Of
course you can write your own custom cell renderer which calculcates
the information for each cell but unless you want to do that, you need
an extra column in your model. Please note that the model columns
don't necessarily correspond to the view columns. It thus doesn't make
any sense to speak of an "invisible" column in a model.


Salut, Sven