Re: Minutes of the GTK+ Team Meeting - 2010-12-14

[Tristan Van Berkom <tristanvb openismus com>]

On Wed, 2010-12-15 at 14:08 +0100, Piñeiro wrote:
> From: Emmanuele Bassi <ebassi gmail com>
> 
> > • treeview refactoring
> > - massive refactoring
> >   - 41 files changed, 13568 insertions(+), 3204 deletions(-)
> >   - GtkCellArea
> >   - moves code out of TreeViewColumn to allow sharing with other cell-based
> >     view widgets (GtkIconView, GtkComboBox)
> > - treeview-refactor ready to be merged
> > - requires another reviewer for the various branches prior to merging
> > ACTION: test treeview-refactor with a very large dataset (kris)
> > ACTION: merge treeview-refactor before next snapshot (tristan, kris)
> > ACTION: review for combo-box-refactor (mclasen?, kris next week)
> > ACTION: review iconv-iew-refactor (mclasen?)
> > ACTION: make GtkTreeMenu internal-only (tristan)
> 
> I have a question that was wandering on my head during some time. My
> idea was review a little all this changes but I didn't have too much
> time, so I will ask directly.
> 
> Are this treeview refactoring mostly internal, or are there specific
> API changes? After this refactoring it would be required to be
> modified the apps using GtkTreeView?

There's one behavioural change, gtk_tree_view_set_cursor() when
specifying "start_editing = TRUE" will no longer toggle the state
of an activatable cell (this used to be the case, we thought it
was an undesirable side effect since the api is more about bringing
attention to a cell for the user to edit but not implicitly 
modifying the data).

Other than that is seals the whole GtkTreeViewColumn structure so
if people are accessing some members of the column directly they
will have to find other means to do this (I dont expect there
to be any valid reason for accessing these members directly though,
we did expose gtk_tree_view_column_get_button() for the sake
of libgail and apps that set tooltips on the column headers).

> 
> Anyway I was also thinking on GailTreeView, the object that provides
> the accessibility support for GtkTreeView. Should gailtreeview work
> after all these changes?
> 

I expect libgail to not need any changes, we paid special attention
that focus navigation was going to work the same way using the new
code... however there could be some fallout I'm not aware of...

Cheers,
      -Tristan