GNOME Bugzilla – Bug 728121
Mismatched GAction and GtkAction accelerators after changing shortcuts
Last modified: 2014-04-29 15:32:27 UTC
i use the F1 key binding for something else with screen. up to 3.10.x i disabled the keybinding for help in preferences / shortcuts. in 3.12. i have set to disabled the keybinding but it is not honored (i get the help screen anyway). steps to reproduce: 1. open gnome-terminal 2. go to preferences / keyboard shortcuts. 3. select the help shortcut. disable it by pressing backspace. 4. press F1. help opens. expected behaviour: the F1 keycode is sent to the running program (in this case: screen). i even created a new binding just in case some default somewhere else was overriding: ALT-F1 for example. F1 would open the help screen for gnome-terminal. distribution: archlinux.
My first guess is that this was caused by: commit a319aeb66f36e728af1b4929ddd69574df838702 Author: Christian Persch <chpe@gnome.org> Date: Sun May 12 22:26:03 2013 +0200 accels: Port accelerators to use GtkApplication Add GActions for the window actions, and use these as targets for the accelerators. Conflicts: src/terminal-accels.c src/terminal-window.c
Created attachment 274258 [details] [review] accels: Consolidate code to edit and clear shortcuts
This is not specific to the help key. This is a mismatch between the GAction accelerators and the GtkAction accelerators. eg., the zoom in/out keys have the same problem.
Does this patch require testing? or is it verified and was posted for information only ? there are no instructions given.
Created attachment 274268 [details] [review] window: Workaround mismatch in GAction and GtkAction accelerators
Comment on attachment 274268 [details] [review] window: Workaround mismatch in GAction and GtkAction accelerators Thanks for the review!
Dupe of bug 727134?
(In reply to comment #7) > Dupe of bug 727134? Yes. Sorry for stepping on your toes, Egmont. I had not noticed the earlier bug and I just saw this one come in yesterday.
*** Bug 727134 has been marked as a duplicate of this bug. ***
proposed patches fix the issue for me. ...but you already know that ;)
Thanks for testing, Tomas.
Review of attachment 274258 [details] [review]: chpe OKed this in #vte on GIMPNet: 14:11 <rishi> chpe: Have you seen the 2nd patch on bug 728121 ? It combines 2 almost identical functions into one. 15:49 <chpe> rishi: that one's ok to commit too :-)
Debarshi: Thanks for your worn on this. A noticable regression compared to pre-3.12 is that the accel keys don't show up in the menu. Could you please address that too (or at least file a new bug)? (I'm testing with gnome-3-12 branch, sorry if it's already fixed on master.)
That's expected since they were removed from the menu with the patch. Keeping them in the menu would be more work, since you'd have to synchronise the accel path enabled/disabled state between the gtkaccelerator based accel paths and the gtkuimanager accel paths.
(In reply to comment #14) > A noticable regression compared to pre-3.12 is that the accel keys don't show > up in the menu. Could you please address that too (or at least file a new bug)? > > (I'm testing with gnome-3-12 branch, sorry if it's already fixed on master.) As chpe says. I explained this in the commit message: "Workaround mismatch in GAction and GtkAction accelerators ... by removing the ones in GtkActionEntry's. As a consequence of this the accelerators will not show up in the menu, but on the positive side changing a shortcut will actually make the old one go away. This should all be nice and dandy when use GMenu in the future."
I don't know anything about GAction, GtkAction, GMenu, gtkaccelerator, gtkuimanager and things like these... but I know that using any such technical term in reasoning why a user-facing feature broke is just plain wrong approach. I mean, the overall goal of development is out users, and not the simplicity/beauty of the code, right? The hotkeys really should be there in the menu. It used to work, then broke. What was the point of refactoring? Why not just revert the broken patch? IMO you shouldn't just commit a fix with a known regression and mark as fixed and pretend everything's okay. Could you please at least file a bug report for the new issue (in case reverting or fixing is not feasible right away)? Thanks!
*** Bug 728844 has been marked as a duplicate of this bug. ***
Should be fixed now, please test with git master.
*** Bug 728543 has been marked as a duplicate of this bug. ***
Reopening. The menu shortcuts are shown correctly on g-t startup. If you change them, though, you have to quit and restart g-t for them to be updated. They should be updated immediately. (Tested with git master.)
Hmm. That works here...
Okay, I just figured out: Works as expected with old-fashioned menu. Doesn't work (but I'm quite sure it used to work) with Ubuntu's Unity menu in the desktop's upper row (--enable-distro-packaging).
Sorry, I was wrong, a319aeb^ (before refactoring started) still produces this behavior. It could be that g-t does something a bit incorrectly which triggers this bug, but it's way more likely that simply Ubuntu's stuff is broken.
*** Bug 705078 has been marked as a duplicate of this bug. ***