! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Keyboard Shortcuts - Window key maps to different "Keys"


Description Anders Conbere 2006-04-28 22:09:29 CEST
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).
Comment 1 Olivier Fourdan editbugs 2006-04-30 16:01:55 CEST
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 :


BTW, thanks for pointing that out, that helped chasing several bugs in the shortcuts editors.
Comment 2 Michael Cronenworth 2006-05-01 13:23:05 CEST
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?
Comment 3 Olivier Fourdan editbugs 2006-05-01 14:47:25 CEST
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. 
Comment 4 Anders Conbere 2006-05-01 15:58:12 CEST
Yep, that makes sense.

Thanks for the prompt responses :)

~ Anders
Comment 5 Jani Monoses 2006-09-08 09:55:40 CEST
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.
Comment 6 Olivier Fourdan editbugs 2006-09-08 17:23:42 CEST
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)
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)
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.
Comment 7 Olivier Fourdan editbugs 2006-09-08 19:29:42 CEST
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.

Bug #1737

Reported by:
Anders Conbere
Reported on: 2006-04-28
Last modified on: 2009-07-15


Olivier Fourdan
CC List:
0 users



Additional information