On Fri, Nov 07, 2003 at 02:45:30PM +0000, Mikhael Goikhman wrote: > On 07 Nov 2003 14:36:55 +0100, Dominik Vogt wrote: > > > > On Fri, Nov 07, 2003 at 01:10:43PM +0000, Mikhael Goikhman wrote: > > > On 07 Nov 2003 10:28:16 +0100, Dominik Vogt wrote: > > > > > > > > That sounds somewhat familiar. I think you are right. So the > > > > problem can be circumvented by either destroying the corresponding > > > > fvwm function: > > > > > > > > DestroyFunc EWMHActivateWindowFunc > > > > > > > > (which affects all windows, not just gkrellm). Unfortunately, it > > > > is not yet possible to disable certain features of the EWMH spec > > > > for individual windows. > > > > > > Destroying this function would be undesirable for modern applications > > > asking the window manager to activate (bring to the user attention) their > > > windows. > > > > > > A better solution would be to introduce Grab command and add "Grab off" > > > to EWMHActivateWindowFunc. > > > > Deja Vu? No, it wouldn't. > > I.e. you say fvwm should know better than the user what to do and > disallow some legitimate functionality. I hope you have a better solution > in mind for this kind of problems regarding fvwm functions.
Like it or not, fvwm functions don't work reliably without the grab. Furthermore, they can not work reliably *because of the way X11 is designed*. Theoretically, one could improve predictability of whether a particular function needs the grab or not, but practically the code is so obscure that it it virtually impossible to do so (partially since it depends on the behaviour of third party software). In the specific case the "Focus" command in EWMHActivateWindowFunc is one of those that requires the grab to prevent a race condition between the pointer being moved while the focus is changed. If the grab is not held in such a context, releasing the mouse button leads to more or less random windows being focused (experience from the past, not something I'm making up). The situation can be improved by using the Schedule command to trigger EWMHActivateWindowFunc or UrgencyFunc (plus any others?) as soon as possible if the grab can not be established immediately. THe code handling scheduled functions should have a similar check too and keep the functions due for execution in the queue until a grab can be established. However, it would be necessary to always make the grab in the scheduler code since it's impossible to predict whether the grab is necessary or not. Ciao Dominik ^_^ ^_^ -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
