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

[Piñeiro <apinheiro igalia com>]

From: Tristan Van Berkom <tristanvb openismus com>

>> 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).

I looked on gailtreeview code, and it is used gtk_tree_view_set_cursor
with "start_editing=TRUE" in one case. In the method cell_edit.

The ATK framework allows to define some actions in order to control
the accessibility objects. In this case it is possible to add actions
for the cells of the tree view. If it is a text cell renderer
editable, the action "edit" is added, described as "creates a widget in which
the contents of the cell can be edited".

Anyway this description is somewhat misleading. cell_edit basically
finds the cell, and use gtk_tree_view_set_cursor to give the keyboard
focus. And I guess that sets start_editing as TRUE in order to start
to edit this cell.

So, after this change on start_editing, will this method work
properly? Could someone still using this action to start to edit on a
cell, and then just start to write on this cell?

If this is the case, as Murray Cummings asked, what it is the purpose
of start_editing? It is now a superfluous parameter?

BR

===
API (apinheiro igalia com)