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
