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. To Reproduce: 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 keybindings. > 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 broken. 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.