On Wed, Feb 18, 2004 at 12:24:02AM +1100, Scott Smedley wrote: > 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?
Yes, and in addition, when the event is received, the modifier mask may differ from the actual state of the modifiers. Some code in fvwm relies on an accurate modifier mask to work correctly, and other programs maybe too. > > 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. I already tried that and failed since if a module or application grabs the keyboard, fvwm never gets the Key... events. > > 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? Something like Key (rxvt) TSIF N do_something The binding code would make sure that only the proper keys and buttonms are grabbed for such windows. Currently, all keys and buttons with bindings attached are grabbed on all windows. > > > + 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? :-P Look at the AddBinding() function in libs/Bindings.c. Basically, given a specific keycode, you just try all possible modifier entries (max. 9) in the Xmodmap and see if they yield the desired keysym. The problem is that only the two entries in the modifier map have a fixed meaning (0 = no modifier, 1 = shift). All others are undefined and can not be queried from the X server, as far as I know. You can not do much more than allowing the user to specify the modifiers and keycodes in addition to keysyms. The switch that gueasses the modifier mask in AddWindow() could be extracted and put into a new function for general use. Ciao Dominik ^_^ ^_^ -- 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]
