Re: Handle Enter pressing at GtkEntry
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. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
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
Re: Handle Enter pressing at GtkEntry
On Thu, Oct 04, 2012 at 06:55:08PM +0900, Tristan Van Berkom wrote: 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: ... Validation is a different problem. For validation, the user should have an instataneous visual clue whether the input would be considered valid (but no blocking of non-conforming inputs, of course). In the second case you mentioned, loading of new values must not happen when there are uncommited changes and that should be also easy to achieve – except it may come a bit too late from the user's perspective if validation needs also be performed. However, if the GUI is constructed so that the user expects immediate commit, as it seems from your description, then it should be probably really immediate. Imagine the case I was talking about as function plotting. You may attempt to plot the function as the user types the expression but (1) the ‘plotting’ thing is not something really instanteneous and so doing it after each keystroke would interfere with typing (2) the user is essentially never interested in displaying the intermediate rubbish, in fact, he may be strongly intereseted in seeing the last meaningful, i.e. commited, output while editing. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the activate signal, but for some reason documentation says Applications should not connect to it. My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, 2012-10-03 at 20:18 +0200, David Nečas wrote: On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the activate signal, but for some reason documentation says Applications should not connect to it. My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti I asked a similar question some time ago https://mail.gnome.org/archives/gtk-list/2012-March/msg00033.html Seems that the irritating statement Applications should not connect to it, but may emit it... http://developer.gnome.org/gtk/stable/GtkEntry.html#GtkEntry-activate is removed for current GTK3. Thanks. http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkEntry-activate ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
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. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
