Yet more treeview musings

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]