Yet more treeview musings

[Marc Mulcahy <marc mulcahy sun com>]

Hi All,

Yet more treeview musings.

Bryan and Bill's proposal from yesterday is a much better separation of the 
concepts of the GtkCellRenderer and the GtkTreeView.  The 
GailTreeViewInterface, which Brian pointed out could be implemented on the 
GailTreeView object directly without need for a separate object, is 
responsible for retrieving the value of each GailCell and updating its 
defunct and stale state based on the state of the GtkTreeView.  Because the 
GailTreeViewInterface retrieves the value of a GailCell on its behalf, this 
implies, without some modifications, that the TreeViewInterface knows what 
sort of renderer the cell is using, and how to get the information out of 
that renderer.  Consider the following hypothetical illustration:

Currently, GailTextCell implements the AtkText interface on behalf of table 
cells which use GtkCellRendererText renderers.  When the contents of a cell 
are updated, the GailTreeView object can look at the renderer for that 
cell, realize that it's a text renderer, and send the appropriate new gchar 
* string to the cell.  No problems here...  Now, let's say someone later 
adds a renderer of type GtkCellRendererInteger, and uses it in a 
GtkTreeView to render integers in the columns of a treeview.  Now, we're 
broken for two reasons-- one being that there is no accessible 
implementation on behalf of the GtkCellRendererInteger, and the other that 
there is no way for the GailTreeView interface to extract the values out of 
cells using the GtkCellRendererInteger to appropriately update the 
corresponding GailCells.

I think I've come up with a solution such that the GailTreeView can 
appropriately update GailCells which use renderer types whith which the 
GailTreeView implementation is not familiar.

1. Add a glist of gvalues to the GailCell object.  This list of gvalues 
will contain the cached value or values of the GailCell.
2. Information obtainable from a GtkCellRenderer is obtained through the 
use of object properties.  So we also need to add a glist of property names 
to the GailCell object.  This is a list of properties, corresponding to the 
list of gvalues, whichh need to be queried when the cell's value is updated.
3. In the signal handlers affecting the reordering, deletion, or insertion 
of cells in GailTreeView, when we've determined that a particular cell's 
value must be updated, we query it for its list of properties, and update 
its gvalue list with the new values of the properties.

The accessible implementation for the new renderer type will of course need 
to manipulate the list of gvalues to extract/modify the appropriate 
information.

In this scenario, GailCellText would contain one gvalue, representing the 
cached value of the "text" property.  The GailCellBoolean, for example, 
would contain two properties which may be of interest in implementing ATK 
interfaces for it, so it would support two gvalues, one for the "active" 
property and one for the "radio" property.  the GailCellPixbufText would 
support at least two gvalues, one for the "text" property, and one 
containing a pointer to the image or other relevant data.  the hypothetical 
GailCellInteger object would contain a gvalue for the "integer" property, 
etc...

The list of property names can be initialized in the factory for the 
appropriate Gail implementation for the renderer type, and the GailTreeView 
implementation need not know any of the details of the accessible 
implementation for the renderer.

Let me know if this seems broken-- I may have missed something, but this 
seems right to me.  I'll proceed for now along these lines.

Marc