GNOME Bugzilla – Bug 696961
GtkSearchEntry should clear contents on Escape
Last modified: 2018-04-15 00:03:14 UTC
I think that when a GtkSearchEntry has focus and the user presses Escape, we should clear the search box, just as if the user had clicked the "clear" icon.
Created attachment 245333 [details] [review] Listen for Escape to clear the GtkSearchEntry contents Please review, Thanks.
some drive-by comments: (1) Please don't use g_signal_connect() but rather overwrite widget_class->key_press_event (2) This depends on UI review first so we know it's actually what we want. Also, should GtkEntry maybe do this already?
(In reply to comment #2) > some drive-by comments: > > (1) Please don't use g_signal_connect() but rather overwrite > widget_class->key_press_eventeful OK. I will try that in the next iteration of my patch. > (2) This depends on UI review first so we know it's actually what we want. > Also, should GtkEntry maybe do this already? Simple GtkEntry should also clear contents upon Escape? I don't think that's the desired behaviour. Escape to clear contents is particularly useful in a GtkSearchEntry because the user maybe looking for many things or may be unsuccessful in finding an instance of a word in a search and hence would need to modify his search query often, so a keybinding to clear the GtkSearchEntry would make the UI that much more convenient. I will check if GtkEntry has this feature already and report back. Thank you for the comments, Benjamin!
Review of attachment 245333 [details] [review]: set patch status according to Benjamins comments
Created attachment 298751 [details] [review] Clear GtkSearchEntry on escape key GNOME Software already does this. Maps and others could profit from this. I think this feature shouldn't be in GtkEntry. The escape key normally corresponds to an action, which is to be aborted and GtkEntry doesn't represent that. E. g. in a dialog the whole dialog should be closed when pressing escape. However aborting a search normally means to remove the filter.
I must say that I prefer to keep it the way that it is now, with the entry emitting signals, but it is the applications responsibility to change the contents.
I filed this originally, and don't feel strongly about at it all. If the GTK team thinks this is best left as is, that's fine with me.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new