After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 452059 - Cannot enter slashes
Cannot enter slashes
Product: gnome-dictionary
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gnome-dictionary-maint
Depends on:
Reported: 2007-06-28 21:40 UTC by Sven Arvidsson
Modified: 2015-02-23 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---

Corrects the bug by removing the line which made forward-slash the accelerator key for 'Find' (1.07 KB, patch)
2014-02-01 12:43 UTC, Saurav Agarwalla
reviewed Details | Review
Changed the patch to conform with the commit guidelines. (1.05 KB, patch)
2014-02-04 07:57 UTC, Saurav Agarwalla
committed Details | Review

Description Sven Arvidsson 2007-06-28 21:40:40 UTC
[ Forwarded from ]

"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."
Comment 1 Luca Bruno 2008-12-28 22:28:11 UTC
This also happens in other applications (like Epiphany).
Comment 2 Saurav Agarwalla 2014-02-01 12:43:11 UTC
Created attachment 267779 [details] [review]
Corrects the bug by removing the line which made forward-slash the accelerator key for 'Find'
Comment 3 Saurav Agarwalla 2014-02-01 15:57:10 UTC
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 <>
>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.
> 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">&lt;Primary&gt;f</attribute>
>-          <attribute name="accel">slash</attribute>
>         </item>
>         <item>
>           <attribute name="label" translatable="yes">Find Ne_xt</attribute>
Comment 4 Sindhu S 2014-02-02 08:54:16 UTC
(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.
Comment 5 Saurav Agarwalla 2014-02-02 14:12:02 UTC
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.
Comment 6 Emmanuele Bassi (:ebassi) 2014-02-02 16:35:32 UTC
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.
Comment 7 Emmanuele Bassi (:ebassi) 2014-02-02 16:39:47 UTC
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:

thanks again for the patch!
Comment 8 Saurav Agarwalla 2014-02-04 07:57:25 UTC
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.
Comment 9 Emmanuele Bassi (:ebassi) 2014-02-04 10:43:17 UTC
Review of attachment 268036 [details] [review]:

looks great now, thanks for your patch!
Comment 10 Emmanuele Bassi (:ebassi) 2015-02-23 15:44:55 UTC
Ouch. This dropped off my radar a long time ago.

I apologize for taking this long to push the commit to master.