On Thu, Oct 4, 2012 at 5:55 PM, David Nečas <y...@physics.muni.cz> wrote: > On Wed, Oct 03, 2012 at 08:19:39PM -0700, Andrew Potter wrote: >> On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev <muta...@rambler.ru> wrote: >> > What is the right way to catch "Enter" pressing at the end of the text >> > input >> > to GtkEntry >> >> gtk_entry_set_activates_default() is probably what you want. > > If you actually want what it does. Usually, I do not want that at all. > > I want to recalculate and update something once user has finished > editing the value there (but not during the editing). This means namely > when the entry loses focus, however, it should be also possible to > invoke the update without leaving the entry, by pressing Enter. So, > instead of gtk_entry_set_activates_default() I use something like > set-activate-on-unfocus and then just handle activate.
I'm curious about this, out of my own personal interest... do we have a workable solution for this "commit-on-focus-out" paradigm ? As I understand, it's not very stable to use focus-out events and, I recall reading a detailed blog about this I can't seem to find at the moment (but it seems the problem is not at all limited to GTK+, just broken by design). Note in many cases validation/apply/commit user input on focus-out does work but... here is a case where I expect it to break: a.) User is presented a form full of entries b.) User tabs or clicks into an entry c.) User modifies data d.) User selects another entry e.) Focus-out causes the previous entry to commit, yay ! f.) User modifies data in new entry g.) User presses "OK" h.) Dialog full of entries is destroyed... oops... previous entry is destroyed before ever receiving focus-out notification. That scenario, easy enough to deal with because you have a "commit" button which can take care of things... (in which case you dont need focus-out in the first place)... but... lets take another example: a.) Editor is loaded into a notebook tab because some object is selected (consider Glade's property editor, and a widget is selected for instance) b.) Each property gets it's current value filled with new data c.) User modifies one of the entries d.) User selects a new entry, YAY we received focus-out e.) User modifies the currently focused entry f.) User selects a new object in the workspace g.) Entries are cleared of previous data, a new widget is loaded into the editing context and new values are loaded into the entries h.) Entry receives focus-out ... OOPS... what change did I have to commit ? As far as I know, it's an interesting, classic problem (which I knew to exist years ago), perhaps focus event delivery is ordered now in such a way that this wont happen ? ... it's really hard to say. Cheers, -Tristan _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list