Re: Yet more treeview musings

[Brian Cameron <Brian Cameron Sun COM>]

Bill:

> >I don't think that this really breaks our plans badly.  It just means that
> >the GailTextCell (and its siblings) also stores a GList of 
> >GtkTreeViewColumnCellInfo structures not just the Renderer (in addition
> >to the GtkTreeRowReference and the GtkTreeViewColumn pointer).
> 
> [snip]
> 
> THis appears to introduce a dependancy of GailTextCell on GtkTreeView, which 
was 
> what we were trying to avoid.  Does this not defeat the purpose of keying the 
> GailCell AtkObject factory on the Renderer type?

Good catch.  Actually I talked on the phone a good bit with Marc
yesterday evening and we caught this problem.  I thought Marc was
going to send an email describing the new design.

Basically we agreed that there should be a 1-to-1 mapping between
renderers and GailCells.

However, for columns that contain multiple cells, we will have to 
manage this in one of two ways:

1. Column's that support multiple cells expose a GailContainerCell
   when ref_at() is called.  This container will contains n GailCells
   that coorispond to the various cells in the column.
2. We represent a column with 2 cells as 2 columns.  In other words
   if there is a table with 4 columns, where 1 column has two cells
   and 3 columns have one cell, then we represent this as a 5 column
   table.

Either way is fairly straightforward to implement.  Choice #2 probably
makes this easier for applications making use of AtkTable.

Brian