Re: Handle "Enter" pressing at GtkEntry

[Tristan Van Berkom <tvb gnome org>]

On Thu, Oct 4, 2012 at 5:55 PM, David NeÄas <yeti 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 <mutab0r 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