After upgrading gtk+ to version 2.24.7, the <Primary> modifier is used instead of the <Control> modifier when setting a keyboard shortcut that uses the control key. Previously set shortcuts that uses the <Control> modifier stopped working. This happens in the keyboard settings and in the Window Manager settings dialogs. This behavior seems to be related to the commit 24a42839babddc8130226663a97453fe8b0f8d45 on the Gtk+ git repository, on 26th of September.
I can confirm this issue. It is appearing on my Arch Linux 64-bit after upgrading the package gtk2 from 2.24.6-2 to 2.24.7-1.
I have informed the author of the commit of the issue and am posting his reply as per his permission: > ...It seems your commit 1f6a921158b5a4fa80ea2e844ce25aad04101aaf in GTK+ 2.24.7 has broken shortcuts using <Control> in Xfce 4.8 on Linux (https://bugzilla.xfce.org/show_bug.cgi?id=8056). Since the commit seems to be a part of OS X updates (http://ftp.gnome.org/pub/gnome/sources/gtk+/2.24/gtk+-2.24.7.news), shouldn't the <Primary> accelerator appear only on Mac OS X? Yep that's known. You probably use a copy of eggcellrendereraccel.c and friends? gnome-control-center fixed this by adding support for <Primary>, but the recommendation is to use GtkCellRendererAccel and *not* parse serialized accel strings yourself (or do both the serialization and deserialization yourself). Using primary on the mac only is not an option, because then we could use <meta> right away, and the whole idea of specifying accels cross-platform would be poof. I know this is an unexpected fallout, but for now we are trying to fix the situation without getting rid of <primary> regards, --mitch
From downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=753312 "gnome-control-center has a workaround for the problem: http://git.gnome.org/browse/gnome-control-center/commit/?h=gnome-3-2&id=e46180ec18192a7954b4e75bca1594ec3ca3ae62" Could we use something similar?
The problem is not that we miss-use some API, we are already using gtk_accelerator_{name,parse} to do all the parsing in both ways. The problem is that we store the "name" of the shortcut which was <Control>... and now is <Primary>.... IMO, the GTK+ guys did a mistake with this, breaking this naming convention in a stable release is not really nice. A quick'n dirty solution would be to replace all occurrences of <Control> with <Primary>. But that'll make <Primary> appear all over the place in the UI and it's not exactly clear that it means Ctrl so we should maybe implement a function which converts the GTK accelerator string into a readable string.
(In reply to comment #4) > The problem is not that we miss-use some API, we are already using > gtk_accelerator_{name,parse} to do all the parsing in both ways. I can reproduce it on Fedora 16. From a first quick look the problem could be solved by using GtkCellRendererAccel with the side effect of localized modifier names.
Don't know if this affects my GTK based Emacs, but.. I used to make a key binding (in Emacs) control-tab. Suddenly (I confess that I upgrade too many packages in Gentoo, so I don't exactly know which causes this problem), 1. Xfce shows <control> shortcut to <Primary>, 2. Emacs (and xev too) cannot catch control + tab. It's like window manage did not pass the key press event to the application.
Fixed in git master branch, we now show the shortcut labels instead of the raw accelerator string.
This seems to be back in x64 XFCE 4.10