Red Hat Bugzilla – Bug 67309
gnome-panel panel_parse_accelerator not parsing <Modn>
Last modified: 2008-05-01 11:38:02 EDT
Description of Problem:
When I bind "<mod4>F1" and "<mod4>F2" say to menu_key and "run_key"
respectively (with gconf-editor) the bindings do not work. Only the
modifiers "<Control>", "<Alt>" and "<Shift>" seems to work, not those
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. change bindings to use "<Mod4>" modifier instead of the default
"<Alt>" in gconf-editor.
Menu and run bindings don't work with mod4 modifier.
Using modN modifiers should work.
"<ModN>" works in metacity and I note that `panel_parse_accelerator'
("panel_util.c") lacks some of the code in metacity's
`meta_ui_parse_accelerator' ("ui.c"), however looking at gtk's
`gtk_accelerator_parse', I don't see why `panel_parse_accelerator'
shouldn't work, or in other words why the extra modifier code in
`meta_ui_parse_accelerator' is necessary.
<grumble>WIBNI `gtk_accelerator_parse' could handle "<Meta>" too
(and "<Hyper>" perhaps).</grumble> I'll try to file a separate
RFE for that though.
I don't think the bug can be in panel_parse_accelerator() - it just
calls gtk_accelerator_parse, no strangeness there.
The problem is the IGNORED_MODS #define, see
So in the mean time can the ModN keys be moved from IGNORED_MODS
Metacity supports <Meta> now?
No, just moving from ignored mods to used mods doesn't work - you do need to
ignore numlock and scroll lock. This is why you have to dynamically sort out
which mods are which.
Metacity supports <ModN>, not <Meta>, it still uses gtk_accelerator_parse(). But
metacity doesn't hardcode the ignored mods, it dynamically locates numlock.
Should be fixed in rawhide, or if not in the next gnome-panel upstream
version we get. But 90% sure fixed in rawhide.