Re: GailTreeView Changes Proposal

[Bill Haneman <Bill Haneman sun com>]

Brian wrote:

>Marc:

[snip]
>The reason GtkTreeView still needs the gint row and column values is
>because we want every GailCell to have two properties:  
>
>  defunct
>  stale
>  
>defunct means that the cell has been removed via a row delete or hidden
>via a row collapse or because a column has been made invisible.
>
>stale means that the cell is still visible, but that the index to the
>cell has changed.  A row-reorder or an insert/delete on a row befor
> the cell would cause this scenario.



I believe that these should be "states", thus defined in AtkState.  That means that 
any AtkObject could have one of these states.  "defunct" generally will be reserved 
for objects that should no longer be used - for instance for GtkAccessible-derived 
AtkObjects this will generally mean that the backing GtkWidget has been destroyed.

Since the code freeze is this week, we need to add these states to AtkState as soon 
as possible.

>> 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.
>
>This is correct.  Now that I'm thinking about it, this idea works well
>as long as GtkTreeView is the only thing using GtkCellRenderer.  Looking
>at the GTK code, this is currently the case, but I'm not sure it's
>guaranteed to stay this way.

I agree with Brian that it would be better to keep GailTreeViewCell derived from 
GailCell, and not rely on the current situation where GtkCellRenderers are only used 
by GtkTreeView.  For all we know, there are custom widgets that are re-using 
GtkCellRenderer right not, so this is not perhaps a safe assumption.

>Perhaps a safer method would be to leave the hierarchy the same, but
>add a void * pointer to the GailCell object and just have the 
>gail_tree_view_table_ref_at function malloc a structure with the needed
>data (the GtkTreeViewColumn pointer and the GtkTreeRowReference).  The
>gail_cell_init() function could take a (void *) userdata argument.
>This might be a more generic solution.
>
>If we do this, then the GailTreeViewTextCell (and any peers) would need
>a finalize function to free this data.  You can refer to the
>gail_tree_view_finalize() function in GailTreeView for an example of
>setting up such a finalize function.
> 
>However, there is still the issue of setting up the callback functions
>that are needed by the various GailCell's that are used by GailTreeView.
>Since these cells need to support the "defunct" and "stale" signals that
>I described above, they need to define callback functions that are 
>listening to the signals.
>
[snip]

I also like Brian's idea of an 'init' function (other than the GType instance init 
function) that handles some of the problems with subclasses.

>I think the best solution is to make the "init" function a function that
>the subclasses can override.  That solves all the init problems.

There are some void* things in the GTypeInfo structure used at GObject type 
registration that I haven't used yet, but they may provide us a means of doing some 
initialization that is not readily accomplished using the GInstaceInit function 
parameters.  Probably this bears some investigation.

-Bill

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland