In settings -> Window Manager Settings -> Keyboard Difference in the two keyboard shortcut locations and they way they handle the Windows Key. Setting a new shortcut to use the "windows key", the keypress registers as "Super(L/R)". In settings -> keyboard -> shortcuts Setting a new shortcut to use the "windows key", the keypress registers as "Mod4" These really are two different things and it's a bit confusing from a users perspective why they might be registering as different keys. (the super keys don't allow for other keys to be mapped along side them where as mod4 does).
Ok, there is a problem with the windows key. Unfortunately, fixing that bug prevents the Windows key to be used in shortcuts. As this is a real bug, the windows key is not supported anymore in the two shortcuts editors. See that thread for more details : http://foo-projects.org/pipermail/xfce4-dev/2006-April/019880.html BTW, thanks for pointing that out, that helped chasing several bugs in the shortcuts editors.
If you manually edit the key mapping file then you can set SUPER_L+D successfully. When I press the Windows Key+D then I can show my desktop. Why is this considered a "fixed" bug?
Yes, this is exactly what I'm saying in mail to the ML. You cannot enter a shortcut based on the windows key (ie "SUPER") because of a limitation in gdk/gtk+ that should be addressed in the forthcoming gtk+ 2.10. However, both the window manager and the shortcut manager support the feature (that's why it works if you edit the fil by hand). So the bug is fixed, there is no more difference between the window manager shortcut editor and the keyboard shortcut editor. The rest is a gtk+ problem => so it's fixed, as far as I'm concerned.
Yep, that makes sense. Thanks for the prompt responses :) ~ Anders
there seems to be a difference with gtk+2.10 among the two shortcut editors in BETA2 (not checked RC1/svn yet) The kb shortcut manager allows to set SUPERL/R (two windows keys) to be used in combination with other keys. The xfwm4 shortcut editor OTOH reacts to SUPER and does not wait for it to be released so the shortcut is going to be that key alone.
Ok, I see what you mean, but I'm not sure the problem lies in our code. Let's see how I can demonstrate that. By default, on my Xorg system, I have the following modifiers defined : shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x71), ISO_Level3_Shift (0x7c) As you can see, Super_L is listed as a modifier but *not* Super_R. That could explain, IMHO, why pressing the right "Windows" key is seen as a regular keystroke and not as a modifier as you could expect. To check that theory, a simple test is to add Super_R as a modifier. Let's proceed as follow: xmodmap -e "clear mod4" xmodmap -e "add mod4 = Super_L Super_R Hyper_L" That should do the trick. Let's checkn rerun "xmodmap" again to see what is now listed as mod4: shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x73), Super_L (0x7f), Super_R (0x74), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x71), ISO_Level3_Shift (0x7c) Great! So now both Super_L and Super_R are listed as modifiers. Now, the last step is to check with the shortcut manager (both keyboard and WM shortcuts) And indeed that works with both. Therefore, I do think that this issue could be related to the default Xorg Xmodmap mapping.
I've now changed the xfwm4 shortcut editor so that it behaves like the keyboard shortcut manager, ie wait for the key release instead of the the key press. That doesn't fix the issue (as explained above), but at least there is no more inconsistency.