On Sun, Jul 04, 2004 at 01:22:21PM -0700, Jason Weber wrote: > 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.
Yes, that's nice, but we still need another option via SendToModule to override this setting. This shouldn't be much additional work. > 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]
pgpqdOrIYqJya.pgp
Description: PGP signature
