Re: GtkFileChooserButton::file-set
Il Thu, 4 Oct 2012 02:00:39 +0200 Rafał Mużyło galtge...@gmail.com scrisse: On Thu, Oct 04, 2012 at 12:33:24AM +0200, Nicola Fontana wrote: Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło galtge...@gmail.com scrisse: but the change on cancel was recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in 2.24 though, even if it seems to be only a matter of a cherry-pick). What I mean is pressing ESC or clicking cancel unset the file name and I didn't find a way to catch it: this is not the same issue. I'm using gtk 3.4.4 but I don't think it is relevant. It's in fact not only the *very same* problem, but also while it *was* fixed on 3.4 branch, there was no release there yet containing this commit from this branch - it's post 3.4.4. I'm interested in the notification not in the fact it is unset: this hardly makes them *very same*. Anyway thanks for pointing out it is unwanted behavior: I'll wait for the fix. Ciao. -- Nicola ___ 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 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
