How about: .IP "*FvwmProxy: Action ModifierRelease \fIcommand\fP" This selects an fvwm function to be called while proxies are shown and any modifier held when the proxies were last activated is later released. The default is Nop.
*FvwmProxy: Action ModifierRelease SendToModule FvwmProxy Hide Hmm, maybe I should word that description a little better. -- _ ( \ _ \ /_ / _ _ Jason Weber Oceanside, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon [EMAIL PROTECTED] // [EMAIL PROTECTED] (/ On Fri, Jul 02, 2004 at 02:05:03PM +0200, Dominik Vogt wrote: > On Fri, Jul 02, 2004 at 01:31:12AM -0700, Jason Weber wrote: > > I used XQueryPointer in the prototype. If there's no objection, > > I can just put something similar back in. > > I have no objections, but we need to add some protocol to inform > FvwmProxy about which modifiers to watch. Perhaps something like > > SendToModule FvwmProxy Show ReleaseModifiers <modifiers> <action> > > where <modifiers> is a modifier string as in the Mouse command (I > think there is some parsing stuff in libs/Bindings.c) and <action> > is either "Abort" or "Activate current proxy" (or whatever we > called this functionality). > > It would be good to not poll the pointer constantly but only when > a message from fvwm arrives, or once per second otherwise. > > > On Fri, Jul 02, 2004 at 03:31:12AM +0200, Dominik Vogt wrote: > > > On Thu, Jul 01, 2004 at 02:10:39AM -0700, Jason Weber wrote: > > > > It looks like key release bindings are gone. Is there a workaround to > > > > get this > > > > or does anyone have a suggestion on how I can fix this? > > > > > > I wish I knew a good way to do this. Key release bindings froze > > > fvwm or FvwmProxy too often to be usefull (e.g. if you opened a > > > menu with the key held down and released it before closing the > > > menu). So I removed the code again. > > > > > > I really like the flexibility of remote controlling FvwmProxy via > > > "SendToModule", but it doesn't work on key release. It's > > > virtually impossible to guarantee no key realeas events are lost > > > unless the keyboard is grabbed, but then either fvwm or FvwmProxy > > > grabs it and the other will freeze (well, if FvwmProxy is remote > > > controlled, it does not need keyboard input, but then we still > > > have to prevent fvwm from running arbitrary functions). > > > > > > One solution might be to let fvwm pass a keycode to FvwmProxy. > > > The module could actively watch the state of the key and close if > > > it has been released. To keep the code simple, we could allow > > > just modifiers (which are easier to watch). > > > > > > > If the focus isn't on a proxy, will FvwmProxy get any alternate > > > > indication of the alt release? > > > > > > Not from fvwm. > > > > > > > I don't suppose the event will hit an X KeyPress. > > Ciao > > Dominik ^_^ ^_^ > > -- > Dominik Vogt, [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
