Re: GailTreeView Changes Proposal

[Brian Cameron <Brian Cameron Sun COM>]

Peter:

> Is the plan to keep instances of the accessible object which is related to
> each cell around in memory?  We specifically decided to NOT do this in the
> Java realm because the number of cells (for example in a large tree or
> table) could be huge.

Well, we were planning that all cells keep a pointer value to their parent
GtkTreeView.  The small overhead of keeping such a pointer allows the
various cells to connect to signals that will notify the cell when its
state has become "stale" or "defunct" and will also allow the cell to
provide signal notification when its value has changed.

Perhaps you are suggesting the cells should not support these features?
If so, then a cell would be a very transient object.  It seems desirable
for the cell to be able to inform its user that the backing data has
changed.

> This is a lot of why cell renderers are used in these
> UI widgets in the first place.  That's why in the Java Accessibility API we
> have the Accessible State 'TRANSIENT', to indicate that the accessible is
> not linked to it's UI widget anymore (and so attaching signal handlers will
> not gain anything).  It's also why we have AccessibleActiveDescendent events
> - so that one can listen for changes happening in descendents of a widget in
> those cases in which one couldn't listen on the widget accessible otherwise.

Perhaps part of the problem is that a "GtkCellRenderer" isn't a very 
intelligent object.  The GtkCellRenderer, by itself, does not know
anything about its backing data.  In fact, the same GtkCellRenderer 
instance is used to draw multiple cells.  In other words, an instance
of the GtkCellRendererText will be used for all cells in the tree that
display text.  In order to "prime" the renderer with the proper cell
information by calling this function:

  gtk_tree_view_column_cell_set_cell_data(tv_col, model, &iter);

After this call informs the renderer what column and cell it is 
actually working with, then the "render" function gets called.

Something tells me that the Java renderer is likely much more smart.  
Perhaps it allows you to grab the cell value directly from the renderer.
Unfortunately Gtk doesn't support this (yet).

> Then you don't associated an accessible with a renderer; you associate it
> with the cell, and build it dynamically based on information you get from
> the renderer.  It then gets thrown away when the AT no longer is needing to
> get information about it.

Unfortunately in the GtkTreeView, there is no single object that 
corrisponds to a cell.  Cells are managed by the GtkTreeViewColumn
but in a dynamic way.  In other words the GtkTreeViewColumn "paints"
each cell because it can calculate the rectangle where the "nth" cell
lives, then it primes the renderer, and then the renderer is used
to paint a small section of the GtkTreeViewColumn.  I'm not sure if
I am describing this well enough for you to get a picture of how
GtkTreeView works, but I hope you are starting to understand that 
there are some inherant limitations which will possibly force the
ATK cell to cache some data about it's parent so it can get access
to the cell data again.

Brian