Created attachment 539637 [details] ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml Description of problem: I recently upgraded xfwm4 to the last version of xfwm4 in updates-testing repository. I had some shortcuts defined which use the key <Control>. After the upgrade they stop working. If, however, I define a new shortcut which uses <Control>, then it works (now it seems to be called <Primary>. I attach a copy of my ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml file Version-Release number of selected component (if applicable): xfwm4-4.8.2-1.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. Have a previous version of xfwm4 installed. 2. Define keyboard shortcuts with make use of <Control> 3. Update xfwm4 to xfwm4-4.8.2-1 Actual results: The previously defined shortcuts won't work
I wonder if this has anything to do with the recent gtk2 update. Did gtk2 update for you around the same time? Adding christoph here for his thoughts.
At first I thought this was an xfwm4 bug as we had some trouble with it recently but now I do think it's indeed gtk. I updated to xfwm4-4.8.2-1.fc15.x86_64 and found out that <Control> + <Esc> as shortcut for xfce4-popup-menu is no longer working. Then I downgraded to 4.8.3-4 but the menu did not come back. And I updated to gtk2-2.24.7-3.fc15 on Tuesday, Nov 29, this falls exactly into the time window Note that the Ctrl key is still working, but it's treated differently. What used to be <Control> has become <Primary>. Smells like gtk to be, but I need to investigate this further.
The gtk 2.24.7-3 update has removed a patch called "keycode-unbind.patch", see http://pkgs.fedoraproject.org/gitweb/?p=gtk2.git;a=commitdiff;h=9100b9fee212 Sounds interesting although I haven't looked into it yet.
Yes, actually at the same time as xfwm4 was updated also gtk2 was upgraded to version 2.24.7-3.
(In reply to comment #3) > The gtk 2.24.7-3 update has removed a patch called "keycode-unbind.patch", see > http://pkgs.fedoraproject.org/gitweb/?p=gtk2.git;a=commitdiff;h=9100b9fee212 That patch was removed because it got upstreamed in 2.24.8. Still, gtk2 is the cuplrit here. Reassigning.
I have meanwhile tried gtk2-2.24.7-3 from koji: A single keytroke of the Ctrl key is now correctly treated as <Control_L> or <Control_R>, but in combination with other keys it becomes <Primary> again.
You probably mean 2.24.8-3. However, the patch in there does not change the part of the keyhandling code at all, so it would be quite surprising that you should see any difference. Anyway, accelerators involving Control work fine in gtk2 applications that I am testing here, like the gimp, as well as in gtk-demo.
(In reply to comment #7) > You probably mean 2.24.8-3. No, this bug was filed against F15 and 2.24.7-3.fc15 is the latest F15 build in koji. The bug we are talking about here was introduced in 2.24.7-1.fc15 and as AFAIK the keyhandling code was changed several times by Michael Natterer before 2.24.7 was released.
libxfce4ui-4.8.0-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libxfce4ui-4.8.0-6.fc16
libxfce4ui-4.8.0-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libxfce4ui-4.8.0-6.fc15
Package libxfce4ui-4.8.0-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libxfce4ui-4.8.0-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-17273/libxfce4ui-4.8.0-6.fc16 then log in and leave karma (feedback).
libxfce4ui-4.8.1-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libxfce4ui-4.8.1-1.fc15
libxfce4ui-4.8.1-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
libxfce4ui-4.8.1-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.