GailTreeView Changes Proposal

[Marc Mulcahy <marc mulcahy sun com>]

Hi All,

I'm working to change the way in which we store column and row information 
in GailCell objects which represent cells in treeviews as per my discussion 
with Brian this morning.  My proposed changes involve the following:

1. GailCell's data members and code will remain the same.

2. A base class called GailTreeViewCell will be implemented.  This class 
will contain the GtkTreePath and GtkTreeViewColumn information.  This 
information provides access to the cell's column and row information such 
that changes in the ordering of rows or columns in the tree view don't 
invalidate this information.

3. GailTreeViewTextCell will derive from GailTreeViewCell rather than 
GailCell.  Future implementations of GailTreeViewBooleanCell and 
GailTreeViewTextPixbufCell will also derive from GailTreeViewCell.

Currently, when the registry is passsed a GtkCellRenderer, it returns the 
factory which creates GailCell objects.  My proposed changes would require 
the registry to be changed to return the factory for GailTreeViewCell 
objects when passed a GtkCellRenderer.

There are a couple possibilities as to how the subclasses of 
GailTreeViewCell should be created.  One possibility is that the 
GailTreeViewCell factory could create the correct type of subclass based on 
the renderer passed to it.  The other possibility is that the factory for 
GailTreeViewCell could just do basic initialization, and leave the 
cell-specific initialization to the ref_at function, or whatever function 
is returning the ATK_TABLE_CELL object to the caller.  My vote is for the 
factory to do the right thing, but this may have negative implications that 
I haven't thought of.  I think this makes sense though, since a 
GtkCellRenderer is only ever used in a GtkTreeView, and creation of a 
GtkTreeViewCell by itself without deriving a subclass for the specific cell 
type doesn't make sense.

Thoughts?

Marc