From: Tristan Van Berkom <[email protected]> >> 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 ([email protected]) _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
