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

[Vlad Harchev <hvv hippo ru>]

On 27 Feb 2001, Havoc Pennington wrote:

> 
> 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.

 As for this - I will try whether returning the even to the event queue (via
XSendEvent) will work  since this approach is much more attractive than
grabbing all possible combinations of modifier keys), and will report it here.

> >  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.

 Thanks for the hint. I'll look into this.
 
> 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.

 I agree to this, but there is no clean way (not requiring linking with Corba)
to force panel to pop up "run.." dialog or menu. Alas. And from usability POV,
there should be a way to intuitively specify shortcuts for apps and for common
operations. The cleanest way is to introduce one more standard that will be
dedicated to shortcuts IMO (and probably host it on freedesktop.org) (exchange
of information whether the shortcut is bound, setting shortcut, reporting
which action to invoke when WM's triggers shortcut, etc)
 
> Havoc
> 

 Best regards,
  -Vlad