On Fri, Jul 27, 2001 at 08:08:58AM -0700, Danek Duvall wrote:
> On Fri, Jul 27, 2001 at 10:27:13AM +0200, Fvwm Workers wrote:
> 
> > I think it would be more correct to blame it on unclutter.  I had a look
> > at the code and it is one big hack,
> 
> I won't disagree.  Sadly, I don't know enough X to even know where to begin
> making it better.
> 
> I noticed that adding -noevents makes it work ok.  That flag makes
> unclutter send a pseudo EnterNotify to the parent window "to try to
> convince applications that we didn't really leave it".  The author uses
> emacs as the primary example of an app that needs this.  Since I don't use
> emacs, this ends up being a reasonable workaround for me.
> 
> But I don't at all understand why that would be necessary, or what the
> interaction is between unclutter and fvwm that's making unclutter screw up
> so badly.  Can anyone explain that?

When unclutter hides the pointer, it creates another window that
is a subwindow of the window that currently contains the pointer.
Then, unclutter waits for a number of events to arrive and destroys
its sub window when it gets one.  One of these events is -
unfortunately - FocusOut.  But some applications (including fvwm)
want to manage the focus of their own, just taking away the focus
from the unclutter sub window under certain circumstances as soon
as it takes focus.

In this case, if any window is entered while a MouseFocus window
has the focus, fvwm deletes the focus causing the FocusOut.  It
may work to not delete the focus if the pointer generally stays
in the same frame.  That should help with the problem at hand,
but it may fail if the pointer is over a sub window of the client
window.

Bye

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]

Reply via email to