GNOME Bugzilla – Bug 78100
Can't assign a shortcut key for a menu option in gnome2.0, this was a feature in 1.4.
Last modified: 2006-11-15 16:10:53 UTC
Using beta3, gedit version 1.116.0 on Solaris 8,
No longer able to hover over a menu item and assign a shortcut key for that
item, this was a feature in 1.4.
1) Start gedit, Click File, hover over the "Open..." menu option, and press
the desired key shortcut .e.g. Ctrl+O.
Expect Result and that in 1.4:
Shortcut key is added to menu opposite label and pressing Ctrl+O, popsup
open file dialog.
Actual result in 2.0:
Key binding doesn't get set.
This feature was available in 1.4 using gedit but not available using gedit
in gnome2.0, a regression from 1.4.
This is due to the fact we use libbonoboui to build our main window
and our menus (actually, but I'm not sure, I think this feature has
been disable in gtk+ 2.0).
Are you able to change shortcut keys in other gnome2 apps?
From the Gtk+-2.0 README:
- Editing of menu accelerators by pressing an accelerator over the
menu item is disabled by default. To enable, it, add:
gtk-can-change-accels = 1
to your ~/.gtkrc-2.0
This enables this feature for standard Gtk+ apps. However, as Paolo
has mentioned, bonoboui seems to broken with regards to this.
There are two things
a) This option is extraordinarily broken UI wise, and confuses the
hell out of loads and loads of real users.
b) The default set of keybindings should be useable - do you need an
extra keybinding in fact ?
c) Gtk+ uses a different mechanism for key binding editing to bonobo,
and as yet no-one has implemented a GUI editor for keybindings for bonobo.
So; this is really a deep future bonobo wishlist item; re-assigning.
> a) This option is extraordinarily broken UI wise, and confuses the
> hell out of loads and loads of real users.
I guess that's why it's disabled by default. But shouldn't you be
allowed to enable it if you really want it?
> b) The default set of keybindings should be useable - do you need an
> extra keybinding in fact ?
Maybe a certain function is only relevant to 1% of the users. So it
doesn't get a usable keybinding. But those 1% of the users, use the
funcion all the time. It would be useful for them to set their own
> c) Gtk+ uses a different mechanism for key binding editing to
> bonobo, and as yet no-one has implemented a GUI editor for
> keybindings for bonobo.
So why not make this work while we wait? It's already disabled by
default (and impossible to enable by mistake), so it won't confuse anyone.
'Just' making it work; you make me laugh.
If it was easy - I would have done it; the problem is - it's not.
Consider, multiple merges, different components in the same
application, having to use the Gtk+ system for keybindings, assigning
keybindings to actions with no GObject, etc. etc.
There are lots of reasons why it's better to wait for a decent
keybinding editor. Sadly I can't lower the severity any more here. If
you're interested in doing the work, I can help show you how to write
a keybinding editor.
One of the best reasons I can see for increasing the priority of this
bug would be changing keymaps. Key bindings are often chosen so as to
group relevant functions on similar areas on the keboard. Try
switching to dvorak and tell me how much sense most of the default
shortcuts make. Just my two cents.
Keelin originally opened this bug on my behalf, before I started
working regularly with Bugzilla.
Personally, I think that not being able to reset shortcut keys is no
great loss. I reported this originally just because it was something
different between 1.4 and 2.0, and I thought there might be something
Removing myself from cc list ...
Switching QA maint to an alias that points at me for easier sorting. Search on
'louie doing alias spam' to find all emails and mark read.
Marking WONTFIX. Almost all apps use Gtk for menus and toolbars now anyway.