Re: Yet more treeview musings

[Brian Cameron <Brian Cameron Sun COM>]

Marc:

> Bryan and Bill's proposal from yesterday is a much better separation of the 

I assume you mean Brian.  :)

> 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:

Okay, I think I know a slight change that will simplify things.

Note that in the GtkTreeViewColumn structure defined in gtktreeviewcolumn.h
that the member variable "cell" corriponds to that column's GtkCellRenderer
value.

I have already mentioned that the gtk_tree_view_column_cell_set_cell_data
GtkTreeViewColumn function defined in gtktreeviewcolumn.c is the function
that "primes" the renderer with the cell value.  If you look at this 
function it just does this (note that the "cell" value is the gtkCellRenderer):

  GValue value = { 0, };

  [...]
  
  cell = (GObject *) tree_column->cell;
  list = tree_column->attributes;

  g_object_freeze_notify (cell);

  while (list && list->next)
    {
      gtk_tree_model_get_value (tree_model, iter,
				GPOINTER_TO_INT (list->next->data),
				&value);
	g_object_set_property (cell, (gchar *) list->data, &value);
	g_value_unset (&value);
	list = list->next->next;

    }

In other words this function is just pulling the value out of the model
with the gtk_tree_model_get_value function and pushing the value into 
the renderer via the g_object_set_property function.

So we could do something like this.

If the GailTextCell object (and its siblings) kept it's own copy
of the appropriate GtkCellRenderer, then it would not be necessary for
the  TreeViewInterface to know *anything* about the data type it is
working with.  In other words, when setting up the GailTextCell (or
any of its siblings) you would just pass in a pointer to the
GtkCellRenderer and it would cache it.  The TreeViewInterface wouldn't
have to care what *type* of GtkCellRenderer it is.

Then when the value changes, the TreeViewInterface would just blindly
get the value with the gtk_tree_model_get_value function and push this
value into the GailCell's renderer with a g_object_set_property()
function call.

The the cell can pull the value out of the renderer itself.  This
means that *only* the GailTextCell (and its siblings) need to know
anything about the renderer, the data type it represents, etc.

This resolves our problems, I belive.

> 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 believe that my suggestion above resolves this issue.

> 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.

This is not necessary if you use the suggestion above.  Since GDK_TYPE_PIXBUF
is a subclass of GType, then it is just contained in a normal GValue.  In
other words, the gtk_tree_view_column_cell_set_cell_data wouldn't work
if a GDK_TYPE_PIXBUF weren't contained in a single GValue.
Since each cell knows its own renderer type, we should just use the renderer
to pull out the actual values out of the GValue.

> 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.

I think it does seem broken.  Do you think my proposal is more
straightforward?  Nonetheless, I don't think changing the code in this
way will be a large change.  Marc?

Anyway, if this isn't clear, then let me know and we should have a phone
conference.

Brian