Re: Editable GtkCellRendererText and focus
On Mon, Jun 11, 2007 at 12:50:48AM -0500, Yevgen Muntyan wrote: What's wrong with the filechooser, by the way? File managers seem to work that way: you say Create Folder and it creates folder. If you're unhappy, you delete it. If you changed your mind while editing name, hit Escape which means Cancel, i.e. No don't create it. How is *switching focus* an indicator of whether you want or do not want a folder on disk to be created? In the original bug report it was argued that the file chooser should not create the folder until enter has been pressed, and the opinions really differ on this one. This falls nicely under point 2 in my other mail -- it depends on what kind of data we are editing whether we should confirm or cancel when the editing stops. Once we revert it will be well possible to make the file chooser only create the folder after explicit confirmation (maybe it works around this already, I am not sure), but I will leave that decision to somebody else ;) -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkCellRendererText and focus
On 6/12/07, Kristian Rietveld [EMAIL PROTECTED] wrote: 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? Looking at the bugs that have been filed over the years, it seems clear that there is no universal solution. We can cop out and add a GtkCellRenderer:commit-on-focus-out property... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkCellRendererText and focus
On Tue, Jun 12, 2007 at 09:34:50AM +1000, Daniel Kasak wrote: Also related: http://bugzilla.gnome.org/show_bug.cgi?id=317387 ... affects cells with a CellRendererCombo as well. I think this is related in a different way, since you currently do not get a signal when the value in the combo box changes, only when you popdown the combo box. This is something we want to fix by adding a changed signal to GtkCellRendererCombo (the patch is there, will work on getting it in 2.12). Apart from that, the combo renderer currently fails to stop editing when the tree view loses focus, another thing which will be fixed soon. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkCellRendererText and focus
On Mon, 2007-06-11 at 17:27 +1200, Tim Evans wrote: In our application, I have run into a problem with the behaviour of GtkCellRendererText when an cell being edited loses focus. The problem appears to be caused by the fix to Bug #164494: bug: http://bugzilla.gnome.org/show_bug.cgi?id=164494 patch: http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkcellrenderertext.c?r1=16769r2=16809 Also related: http://bugzilla.gnome.org/show_bug.cgi?id=317387 ... affects cells with a CellRendererCombo as well. gtk2-perl script is attached to above bug. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
