Maybe I need an example. Do you mean to deactivate it or change the command string dynamically?
Do I just expose '*FvwmProxy: Action' as 'SendToModule FvwmProxy Action' or maybe call it ReplaceAction? -- _ ( \ _ \ /_ / _ _ Jason Weber Oceanside, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon [EMAIL PROTECTED] // [EMAIL PROTECTED] (/ On Mon, Jul 05, 2004 at 02:15:45PM +0200, Dominik Vogt wrote: > 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] -- 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]