Hi Dominik, Thanks for the feedback, muchly appreciated.
> In your example, you hold down > Ctrl and tap tha Tab key. The modifier mask has the bit for > the Ctrl key set. Yep. > Now the event is passed on, but when it is > processed by fvwm or the receiving application, the real > modifier mask may have already changed. I'm not sure what you mean. If the modifier mask changes that implies another event is generated. Are you just saying that the associated KeyRelease event never gets sent to the application? > This can lead to > erratic behaviour. For example, an application may wait for a > KeyRelease event that will never come. Yes, I get the feeling that modifying FVWM to allow KeyRelease events to get through would be a challenging hack at best. Is this a fair synopsis? I guess it would involve remembering which KeyPress events FVWM lets through & adding some sort of handler to KeyRelease events to check if there's an associated KeyPress event that got sent through. If there is, send the KeyRelease event through & "forget" the KeyPress event. > it's impossible to determine to which > window the event has to be sent. There is no guarantee that > the top level client window is able to handle key events. Agreed. > I'll accept a patch that duplicates the FakeClick syntax (or > better: unifies both commands to use the same core loop). I can do that. > The application-specific-bindings problem, however, can only be > solved in a different way. The binding syntax and code can be > enhanced to allow window selection similar to the Style command. Can you please elaborate? > > + e.xkey.type = KeyPress; > > + e.xkey.state = 0; // TODO: Ctrl/Shift/Alt/Meta etc. On a slight tangent, do you know how I can get the modifier state from the string name of a keysym? SCoTTie! :) -- 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]
