http://git.xfce.org/xfce/libxfce4ui/commit/?id=e56596a37ffdb4fe8fda4491466e6f826270accc: From e56596a37ffdb4fe8fda4491466e6f826270accc Mon Sep 17 00:00:00 2001 From: Jérôme Guelfucci <jeromeg@xfce.org> Date: Tue, 18 Dec 2012 07:21:03 +0000 Subject: Improve key comparison. Remove horrible hardcoded hack and use the recommanded way of comparison described in the GDK documentation instead. -- I gave the 4.11 a try and am now suffering from this bug: Steps to reproduce: 1) Assign a command "a" to a key e.g. XF86Sleep. 2) Assign a command "b" to that same key but with <Super> modifier: <Super>XF86Sleep. The settings dialog handles and shows these assignments correctly, and using xfce4-settings-editor, one can confirm that these assignments are correctly saved. 3a) Hit XF86Sleep. 3b) Hit <Super>XF86Sleep. Expected results: In case 3a), command "a" is executed. In case 3b), command "b" is executed. Actual results: In both cases 3a) and 3b), command "a" is executed. DBG[xfce-shortcuts-provider.c:288] xfce_shortcuts_provider_property_changed(): property = /commands/custom/<Super>XF86Calculator TRACE[xfce-shortcuts-grabber.c:311] xfce_shortcuts_grabber_grab(): Grabbing <Mod4><Super>XF86Calculator TRACE[xfce-shortcuts-grabber.c:315] xfce_shortcuts_grabber_grab(): Keyval: 269025053 TRACE[xfce-shortcuts-grabber.c:316] xfce_shortcuts_grabber_grab(): Modifiers: 0x4000040 TRACE[xfce-shortcuts-grabber.c:355] xfce_shortcuts_grabber_grab(): Keycode: 148 TRACE[xfce-shortcuts-grabber.c:519] xfce_shortcuts_grabber_event_filter(): Looking for XF86Calculator ... TRACE[xfce-shortcuts-grabber.c:449] find_event_key(): Comparing to <Super>XF86Calculator TRACE[xfce-shortcuts-grabber.c:457] find_event_key(): Positive match for <Super>XF86Calculator ... TRACE[xfce-shortcuts-grabber.c:457] find_event_key(): Positive match for XF86Calculator Note how the grabber didn't respect our <Super> key. The same works fine with the <Shift> key: DBG[xfce-shortcuts-provider.c:288] xfce_shortcuts_provider_property_changed(): property = /commands/custom/<Shift>XF86Calculator TRACE[xfce-shortcuts-grabber.c:311] xfce_shortcuts_grabber_grab(): Grabbing <Shift>XF86Calculator TRACE[xfce-shortcuts-grabber.c:315] xfce_shortcuts_grabber_grab(): Keyval: 269025053 TRACE[xfce-shortcuts-grabber.c:316] xfce_shortcuts_grabber_grab(): Modifiers: 0x1 TRACE[xfce-shortcuts-grabber.c:355] xfce_shortcuts_grabber_grab(): Keycode: 148 TRACE[xfce-shortcuts-grabber.c:519] xfce_shortcuts_grabber_event_filter(): Looking for <Shift>XF86Calculator ... TRACE[xfce-shortcuts-grabber.c:449] find_event_key(): Comparing to <Shift>XF86Calculator TRACE[xfce-shortcuts-grabber.c:457] find_event_key(): Positive match for <Shift>XF86Calculator ... And here is the old grabber version: TRACE[xfce-shortcuts-grabber.c:526] xfce_shortcuts_grabber_event_filter(): Looking for <Hyper><Super>XF86Calculator
Created attachment 5171 restore-super-key-functionality-hack.patch Attached is a patch that fixes this problem *for me*. Note that it might not (read: certainly will not) work for all configurations and is only a rude hack. It looks for the mod4 modifier and whenever it finds one, it deletes it and restores it as the super modifier, which can be matched in find_event_key, which I had to patch too (see the hack). A similar fix might be needed for other GDK modifiers (hyper, super...). I'm sure it can be done in a better way, but at the moment I can't spend more time on it.
Some sort of drawback with that hack is that the shortcuts are now displayed as if the <shift> modifier had been pressed. Examples: <a> is displayed as A, <Shift><a> as <Shift>A. Verifying in xfce4-settings-editor, it is stored properly as <Shift>a and it works correctly too.
Is it possible to fix this? Since it is a regression is it possible for us to revert that commit? This functionality is of importance as I map <SUPER>F11 to single screen and <SUPER>F12 to multiscreen.
(In reply to Harald Judt from comment #2) > Some sort of drawback with that hack is that the shortcuts are now displayed > as if the <shift> modifier had been pressed. Examples: <a> is displayed as > A, <Shift><a> as <Shift>A. Verifying in xfce4-settings-editor, it is stored > properly as <Shift>a and it works correctly too. Isn't that just how the UI displays all shortcuts?
I've done a bit of testing just now and could not reproduce the issue in the way it is described. Steps to reproduce: 1) Assign command "A" to key "A" e.g., notify-send "no mods" 2) Assign command "S" to key "Super+A" e.g., notify-send "super" 3) Assign command "C" to key "Ctrl+Super+A" e.g., notify-send "ctrl+super" 4) Keep in mind Ctrl+A is already assigned to Select All 5* Press A, notice command S runs instead of command A 6) Press Super+A, command S runs 7) Press Ctrl+A, Select All is performed on focused selectable 8) Press Ctrl+Super+A, command C runs Analysis: libfxce4ui treats input coming without modifiers as if it had the "Super" modifier. However, the presence of another modifier will prevent libxfce4ui from ignoring the fact that "Super" isn't set. Expected behaviour on above steps: 5* A runs A 6) Super+A runs S (current behaviour) 7) Ctrl+A runs Select All (current behaviour) 8) Ctrl+Super+A runs C, provided the two modifiers are pressed before A (current behaviour) NB this bug does not appear related to priority issues between keys and mods as discussed in other reports.
(In reply to Steve Dodier-Lazaro from comment #4) > (In reply to Harald Judt from comment #2) > > Some sort of drawback with that hack is that the shortcuts are now displayed > > as if the <shift> modifier had been pressed. Examples: <a> is displayed as > > A, <Shift><a> as <Shift>A. Verifying in xfce4-settings-editor, it is stored > > properly as <Shift>a and it works correctly too. > > Isn't that just how the UI displays all shortcuts? I don't think so. Behold the difference in the key assignment dialog (the small dialog where you enter the shortcuts) and the results in the keyboard shortcut list. IMO, they should be the same.
Sorry, my last comment might not have been very helpful. Another attempt: > Isn't that just how the UI displays all shortcuts? It is, but the way it does without what I call the hack seems to be the right one, that is: <a> => a <shift>+<a> => A <super>+<a> => Super + a <super>+<shift>+<a> => Super + A "The hack" - you might call it "workaround" - works, and I've been using it happily for over a year now. However, I do not believe it is the proper solution. The proper solution would be to find out what causes the mod4/super modifier to not be recognized correctly. So, as a result of such a proper solution, we should see the above correct GTK presentation of shortcuts with correct functionality. On the other hand, the hack might be necessary, even with these optical aberrations. Because another complication here might be the difference between the presentation and parsing that presentation. Note that there are other exceptions that had to be made, see bug #8744: /* If Shift was used when translating the keyboard state, we remove it * from the consumed bit because gtk_accelerator_{name,parse} fail to * handle this correctly. This allows us to have shortcuts with Shift * as a modifier key (see bug #8744). */ if ((modifiers & GDK_SHIFT_MASK) && (consumed & GDK_SHIFT_MASK)) consumed &= ~GDK_SHIFT_MASK; You will notice that these keyboard shortcut grabber bugs are my favourites ;-)
I can no longer reproduce this. I will check on other machines and close this bug after verification.
Which setup? I can still reproduce this
Shuhao, please try the patch in this bug report and report back if it changes anything for you.
Another weird thing: When I add a non-existing command, e.g. "b" for <super><b> and "bsh" for <super><shift>b, the presentation in the error dialog that opens when trying to exiting this command via the shortcut differs from that in the xfce4-settings dialog (and assignment dialog). In the error dialog, it is written as above, while in the other two dialogs they are presented with a capital letter B. This is both with and without my patch, however. What's more strange: After I have assigned the command bsh to <super><shift><b> and hit this shortcut combination, the error message appears, but also a notification that bouncing keys have been enabled/disabled. Interestingly, this is not reflected in the xfce4-accessibility-settings.
By no longer reproduce this you mean with the patch attached?
(In reply to Shuhao from comment #12) > By no longer reproduce this you mean with the patch attached? No, without the patch. Sorry, but why don't you simply try the patch and see if it solves your problem?
The <Super> modifier seems doesn't work. There is a quote from opensuse-xfce mailing list: http://lists.opensuse.org/opensuse-xfce/2014-12/msg00002.html
What do we need for info? I'm not sure on how to compile it and actually get it to take effects on Xubuntu... so I'm not sure how I can test the patch
Simple steps for a start, best thing is to pay a visit to #xfce-dev on IRC and ask there in case of troubles: 0) Make sure you have all requirements installed (header packages etc.; autogen will tell you if something is missing, but often not exactly what and it depends on your distribution). 1) Check out the latest git version: git clone git://git.xfce.org/xfce/libxfce4ui 2) Apply the patch with patch -p1 < restore-super-key-functionality-hack.patch. 3) Execute ./autogen.sh --prefix=/usr make make install
As discovered and confirmed on IRC, this bug is still reproducible with combinations like these: <Super>-<F12>: xfce4-about <F12>: xfrun4
I have properly commented and applied the "fix" in http://git.xfce.org/xfce/libxfce4ui/commit/?id=b680e8b9f6b0cf1c706ed430a548590daa1f4565. Let's hope this does not break anything, and someone finds a proper solution one day.