albrecht_at_auto.tuwien.ac.at (Albrecht Kadlec) writes:
> 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).
>
> 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.
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: jmp_at_inesc.pt 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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Feb 13 1997 - 21:57:14 GMT