Subject: FVWM: fvwm / FvwmAuto problem

From: [email-masked] (Albrecht Kadlec)
Date: Tue, 11 Feb 97 20:37:59 +0100

start FvwmAuto 100

	put 2 somewhat overlapping windows on a screen
	
	go to window A

	go to window B, (not touching root)

	go back to A, _before_ B is _raised_, but be sure to 
	stay in	the area, where the 2 windows overlap.

the last 2 steps must happen very quickly (just leave A for 50 ms)	

focus keeps toggling between the two windows and they'll be raiseed
alternatively, until the mouse leaves the space where the 2 windows
overlap.

after a few tries you'll get the feeling how to trigger the effect.

So this is a _very_ bad interaction between fvwm2 & FvwmAuto.

>From my debug output FvwmAuto behaves correctly, so what seems to happen
is: 

apparently, FvwmAuto gets a new focus event _after_ the raise, 
which was originated _before_ the raise.
The raise event triggers a new focus event (since we're in the overlap
area).

time	fvwm:				FvwmAuto:

 |	focus B
 |	focus A, because we re-entered	timeout expires, while we haven't
 |					seen the focus A yet  -> raise B
 v	focus B, because it's on top	timeout expires, but we haven't
					seen the focus B yet  -> raise A
and so on.

the 100ms just seem to be >= the round trip delay of the 
	FvwmAuto (raise) -> fvwm (focus) -> FvwmAuto (receive new focus)
path.

so the two columns seem to be executed in parallel, with the "left hand not
knowing what the right hand does"

I tried to get an interval where this effect is triggered:

	I got down to 70ms
	raising to 200 ms also

	raising the timeout to 300 ms, I noticed an interesting effect:
	the flipping stops after some time:

	I got 6, 65, 3, 5, 4, 16, 63 flips so far

Increasing the time slows down the FvwmAuto column in the above timing
diagram, so at some point the next focus event from fvwm arrives, before
the timeout elapses, so the raise is cancelled.

Can anybody suggest a solution ?

I guess, adding a paragraph to the man page saying:
	don't set timeout below 
	"complex-fn-depending-on-system-speed-load-and-windowsizes"
is out of question.

you can get my current developer-version from
	<URL:http://www.auto.tuwien.ac.at/~albrecht/FvwmAuto.c.gz>

albrecht
-- 
I was in the kitchen		Seamus, that's the dog was outside
Well, I was in the kitchen	Seamus, my old hound was outside
Well, you know the sun was sinking slowly
But my hound just sat right down and cried	-- Pink Floyd, "Seamus"
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Jose M. Pereira)
Date: 14 Feb 1997 03:56:40 +0000

> 	"complex-fn-depending-on-system-speed-load-and-windowsizes"

Been there (I once made an FvwmAuto -- in a module written in Python, posted
once upon a time in this list, which included FvwmClean, FvwmAudio and
similars). I remember a quick argument with Rob about it. To summarize:

- AutoRaise can only be reliable if done by fvwm. (I think I couldn't convince
Rob of this, sigh)

- Rob had no intention of bringing AutoRaise back from a module.

- You have to live with FvwmAuto and fvwm functioning asynchronously. That
means the "black dot", transient window overlapping etc. can't be completely
avoided.

Your extensive testing (much better than mine!) seems to reinforce my
conclusion. Sorry.

PS:
If you have any suggestions to hack out the "black dot", I'm ready to try
anything -- my sparc10 is always slower than me :-) 

-- 
Jose' Pereira
	     INESC (Inst. Eng. Sistemas e Computadores)
             R. Alves Redol 9, 6. 1000 Lisboa, PORTUGAL.
             Phone.: +351 1 3100223 Fax...: +351 1 3145843
 e-mail: [email-masked] PGP PUBLIC KEY: finger -m pereira @sabrina.inesc.pt
		<< Hit any user to continue >>
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].