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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri Nov 07 2003 - 09:05:21 GMT