On Mon, Jun 11, 2007 at 05:27:05PM +1200, Tim Evans wrote: > I've attached a small PyGTK script that illustrates the problem. Our > users are presented with a GtkTreeView containing a list of strings to > edit. Having changed the values to their satisfaction, they click "OK". > The problem is that the last change they make is not applied: no > 'edited' signal is emitted on the GtkCellRendererText, so my code does > not modify the underlying model.
This is not a really easy problem :) I think we have to take two things into account when contemplating about this: 1. What to do when the tree view loses focus? Do we leave the cell in editing mode, or do we stop editing. Years ago, I think in 2.2 already, we have made changes to stop editing as soon as focus was lost. I think this has been working well over the last few years. 2. When we stop editing, do we confirm or cancel the changes? It feels like this decision can depend on what kind of data we are editing, etc. I actually tend to agree with Tim here that we should probably commit the values when we lose focus. This is more or less equivalent with what spreadsheets do -- I am only thinking about what users might compare this editing functionality with here, GtkTreeView is not and will not become a table/sheet widget ;) If applications really need confirmation via enter or something else, I'd say they can hook into the entry and maintain a flag whether entry was pressed yes or no and use that information in the "edited" callback to decide whether to change the model or not. Personally, I've been disliking the cell editable API, because of its short-comings, it's high on my list for redesigning. So, if there are no objections, maybe we should revert. Opinions? regards, -kris. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list