User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1 Build Identifier: Happens with rev 27529 of trunk. When creating a new shortcut using the "Shortcut tab" of the "Keyboard settings" dialog, extra things like <Mod2> <Mod4> are added in most cases, making the shortcuts unusable. Reproducible: Always Steps to Reproduce: 1. Create a shortcut by pressing the add button 2. Enter the name of an application 3. Press some keys Actual Results: If I press Control + i, Control<Mod2>i appears in the dialog. If I press <Mod4> + i (windows + i), <Mod2><Mod4><Super>i appears in the dialog. etc.
*** Bug 4332 has been marked as a duplicate of this bug. ***
With numlock on I get "<Mod4><Super>Super_L" when I try to enter in a shortcut with the super key...
With numlock, when pressing super key + i: <Mod2><Mod4><Super>i Without numlock: <Mod4><Super>i
I'll look into it as soon as I can. I have an idea on what is wrong already: When shortcuts are defined by the user, the modifier mask is passed unchanged to gtk_accelerator_name(). When the user presses a shortcut however several less relevant modifiers (like Numlock) are stripped from the modifier mask prior to the gtk_accelerator_name() call. I'd somehow like to have a static libxfce4settings library or at least a common/ directory inside xfce4-settings for functionality used in both, xfce4-settings-helper and the settings dialogs. Any objections? Then I could use the same functions to parse shortcuts in the helper and in the dialog and don't have to duplicate code.
I don't think a library is a good idea. In the pointers code I have one funtion in both the daemon and dialog, with a simple note that there is another function in foo.c that is identical. If we're talking about 1 function, just Ctrl+C/V it, put a note in both of them to the other function and you're done. Don't make it too complicated for a small amount of dupplication.
(In reply to comment #4) > I'll look into it as soon as I can. I have an idea on what is wrong already: > When shortcuts are defined by the user, the modifier mask is passed unchanged > to gtk_accelerator_name(). When the user presses a shortcut however several > less relevant modifiers (like Numlock) are stripped from the modifier mask > prior to the gtk_accelerator_name() call. I'm not so sure -- in my case, when the dialog parses the modifier mask, it sees (GDK_MOD4_MASK | GDK_SUPER_MASK), but when I actually press the key, and the settings helper handles it, it only sees GDK_MOD4_MASK, no SUPER. > I'd somehow like to have a static libxfce4settings library or at least a > common/ directory inside xfce4-settings for functionality used in both, > xfce4-settings-helper and the settings dialogs. Any objections? Then I could > use the same functions to parse shortcuts in the helper and in the dialog and > don't have to duplicate code. Yeah, up to you if you think it's worthwhile and there's enough duplicated code, but I don't think it will solve this particular problem. Neither mod4 nor super are filtered out of the modifier list in either place -- the issue is that the dialog and X are seeing different things. I could be wrong tho; I didn't look too deeply. (Nick, he's not talking about a new shared library; he's just talking about a static non-installed library in xfce4-settings that gets compiled into a couple different binaries in the same package, and is discarded afterwards.
Ok, it should be fixed with revision 27628: * dialogs/keyboard-settings/shortcut-dialog.c: Ignore GDK_SUPER_MASK, GDK_HYPER_MASK and GDK_META_MASK when parsing key release events. xfce4-settings-helper handles X events instead of Gdk events and unlike Gdk X doesn't know which of the Super, Meta and Hyper keys are mapped to Mod2-Mod5. Having <Super>, <Meta>, <Hyper> or even <Super>Super_L in the accelerator name will cause the saved shortcut names to be different than the ones generated by parsing X key events. This should fix bug #4304 although I suppose it would be nicer to determine which keys are mapped to Mod2-Mod5 when parsing X key events from the semantic point of view. I'm sure there is a better way (as indicated in the commit message above), but this way it should at least work. Numlock still makes a difference which probably makes sense because e.g. <Control>a and <Control>A may be used for different commands. Please test and let me know if it works for you.
Oh, and I didn't introduce a common/ directory since now the shortcuts are parsed differently in xfce4-settings-helper and the settings dialog, due to the before mentioned GDK-only modifier types.
(In reply to comment #7) > this way it should at least work. Numlock still makes a difference which > probably makes sense because e.g. <Control>a and <Control>A may be used for > different commands. Erm, yeah, that's obviously complete bullshit. NumLock has nothing to do with switching between lowercase and uppercase. CapsLock/ShiftLock should already be ignored depending on the modifier mapping by ignoring GDK_LOCK_MASK. I'll see what I can do to ignore NumLock as well.
Ok, revision 27632 should hopefully fix this issue. Here's another detailled commit message explaining what goes on in the code: * dialogs/keyboard-settings/shortcuts-dialog.c, xfce4-settings-helper/keyboard-shortcuts.c: Add two new functions called get_modifier_masks() and get_ignore_mask(). The first determines to which of the Mod2-Mod5 modifiers CapsLock, NumLock and ScrollLock are mapped and generates a modifier mask for them. The latter combines this mask with the IGNORED_MODIFIERS mask which we already used before and which includes GDK_HYPER_MASK etc.. This mask is then used in several places to avoid these modifiers to appear in the result of gtk_accelerator_name() and to properly grab the shortcuts. This should fix bug #4304.
I can confirm the last commit makes the key grabbing fully functional, even when NumLock is on. Thank you Jannis ! I'm marking this as resolved.