GailTreeView Changes Proposal

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.



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