Re: [PATCH to panel] popup menu and "run" dialog independant of the state of ScrollLock and NumLock

[Havoc Pennington <hp redhat com>]

Vlad Harchev <hvv hippo ru> writes: 
>  I just tried to really work with a patched panel. If "Run.." dialog is
> invokable via Ximian's "Ctrl-Mod4-r", then I CAN NOT TYPE "r" in any widget of
> any window! ( use safwish as wm, and when I press 'r', the window it's typed
> in quivers. It appears this is how X works :( So, don't apply this patch yet -
> it breaks things.
> 
>  So, to work around this X's limitation, we can grab all possible combinations
> of "uninteresting" modifiers (combined with a fixed value for combination of
> "interesting"), and the fewer uninteresting combinations we
> have, the better (i.e. it's our intereset to not support supersets of
> "meaningful" modifiers - i.e. if the original binding is "ctrl-alt-r", it
> shouldn't be activated if "ctrl-alt-super-r" is pressed IMO). But with this
> approach there is still a need to know which modifiers are not meaningful
> (which ones correspond to keys treated as numlock and scrolllock). I think
> that we should hardcode typical values a usual 105-key keyboard has, and check
> some environment variable for a mask containing all "not meaningful
> modifiers" - if it's defined, then use its value as a bitset of "not
> meaningful" modifiers.
> 
>  What do you think?
> 

If you look at gtk+/gdk/x11/gdkkeys-x11.c in the unstable GTK tree,
there's code which finds the "mode switch" modifier, you could use the
same code to determine the modifier corresponding to NumLock and
ScrollLock.

Though, I think this whole approach is sort of broken; I'm guessing
that a better solution would be some way to let the window manager
handle the keybindings.

Havoc