GNOME Bugzilla – Bug 452059
Cannot enter slashes
Last modified: 2015-02-23 15:45:05 UTC
[ Forwarded from http://bugs.debian.org/430549 ] "The slash-key brings up the `Find' dialogue unconditionally; this makes it impossible to enter "/" characters into the `Look up' field, so it's impossible to look up terms like "input/output". It's also impossible to enter slashes into the Find dialogue once it appears."
This also happens in other applications (like Epiphany).
Created attachment 267779 [details] [review] Corrects the bug by removing the line which made forward-slash the accelerator key for 'Find'
Comment on attachment 267779 [details] [review] Corrects the bug by removing the line which made forward-slash the accelerator key for 'Find' >From b2260f3a25f440ac6d7e637d2370c0791ff7695d Mon Sep 17 00:00:00 2001 >From: Saurav Agarwalla <saurav_agarwalla@yahoo.com> >Date: Sat, 1 Feb 2014 18:05:36 +0530 >Subject: [PATCH] Modified gnome-dictionary-menus.ui which made forward-slash as the key accelerator. > >That line was causing 'Find' to be called whenever the user pressed forward-slash button. Removing it causes 'Find' to be called only when the user presses <Primary>F. > >https://bugzilla.gnome.org/show_bug.cgi?id=452059 >--- > data/gnome-dictionary-menus.ui | 1 - > 1 file changed, 1 deletion(-) > >diff --git a/data/gnome-dictionary-menus.ui b/data/gnome-dictionary-menus.ui >index c21b8df..7ffcd9a 100644 >--- a/data/gnome-dictionary-menus.ui >+++ b/data/gnome-dictionary-menus.ui >@@ -78,7 +78,6 @@ > <attribute name="label" translatable="yes">_Find</attribute> > <attribute name="action">win.find</attribute> > <attribute name="accel"><Primary>f</attribute> >- <attribute name="accel">slash</attribute> > </item> > <item> > <attribute name="label" translatable="yes">Find Ne_xt</attribute> >-- >1.8.3.2 >
(In reply to comment #2) > Created an attachment (id=267779) [details] [review] > Corrects the bug by removing the line which made forward-slash the accelerator > key for 'Find' The patch is fine but the remaining part of the fix is that the quick find field must show up when slash is pressed and mouse caret has focus in the "description" (where the results are shown) widget.
Hmm. But there is already a shortcut to bring up 'Find' i.e. <Primary>F. Do we really need a slash? I am a newbie. So, I don't really know if that is by the developer's choice.
back in the day when I wrote gnome-dictionary, the "slash" was a quick shortcut for search used by console applications. to be fair, I never saw anything in the dictionary sources that had a forward slash, so I never really cared about potential collisions with the look up entry. I'm not sure it's worth having the slash key bound to the search any more, and it's more consistent to have the Ctrl + F key combination only.
Review of attachment 267779 [details] [review]: thanks for the patch. it looks good to me. the commit message could be a bit better, though. the first line should be something like: Drop slash for the search action which describes what the change is about, instead of what actually changed (what changed is visible when looking at the commit log because Git can easily show the diff alongside the commit message). the description should wrap at 72 or 74 columns, but the content of the text looks okay already. it would be great if you could rework the commit message to be in line with the Git commit guidelines used by GNOME: https://wiki.gnome.org/Git/CommitMessages thanks again for the patch!
Created attachment 268036 [details] [review] Changed the patch to conform with the commit guidelines. Thank you all for the reviews. I have changed the commit message in accordance with the guidelines.
Review of attachment 268036 [details] [review]: looks great now, thanks for your patch!
Ouch. This dropped off my radar a long time ago. I apologize for taking this long to push the commit to master.