>>>>> "Jon" == Jon Mountjoy <jon_at_fwi.uva.nl> writes:
Jon> Hello Folks,
Jon> Many folks have experienced this problem, and I think it may have
Jon> been the cause of a couple of complaints here on the list as
Jon> well.
Jon> patchlevel 38, version 2
Jon> When fvwm is called as the last thing in the .xinitrc, and in the
Jon> .xinitrc there are a lot of calls to programs which take some
Jon> time to start up, then there seems to be some race condition and
Jon> some windows are not `captured' by fvwm, or get the wrong colour
Jon> border, or in the worst cases, fvwm doesn't work at all and you
Jon> need to log in else where to kill everything off.
Jon> I can get around it by either of the following:
Jon> [1] Not making fvwm the last entry in my .xinitrc, and making
Jon> say a console window instead. Of course, this means that I have
Jon> to kill the console window to exit.
Jon> [2] Leaving it as the last entry, but starting up any heavy programs
Jon> via the Init function of .fvwmrc
Jon> This seems to work, and avoid the situation.
Jon> I suspect some race condition error in fvwm on start up.
Jon> Could somebody else try putting fvwm as last call in .xinitrc
Jon> with 15 "xload &" programs before it :-)
I tried this here (under AIX) and couldn't reproduce any problems.
All 16 xloads came up just ducky. My suggestions:
1) What system are you on again (Solaris?) and what compiler (&
options) did you use to compile fvwm? If you used gcc, certain
versions of it are buggy, and if you're using -O3 or higher
(under whatever compiler) that may be a mistake as well. Try
compiling fvwm w/ -g and run it w/ -debug to see if this clears
anything up. Also, what does FvwmIdent show for the windows that
didn't get captured as opposed to those that it did?
2) If you can't solve it, kick those things off w/ a sleep in front
of them if they need to be delayed -> (sleep 5; xload &) &
That way fvwm should start up before they come up, but still be
the last thing in the .xinitrc. Or, put a sleep 10 just before
running fvwm, to give everything time to come up first. Most
sample .xinitrc files seem to do this for everything, so this may
be a potential problem with all window managers.
The only potential problems I can see is if one of the windows happens
to be coming up while fvwm is traversing the window list capturing the
windows (so it wouldn't be in the window list) and didn't get a
notification that a new window appeared (why, I don't know). I'll
look through the code and see if there is anything glaring (which I
doubt - if there is a bug it'll be a subtle one).
Also, I imagine that a 'Recapture' should pick those windows up again.
Chuck
*******************************************************************************
Charles K. Hines <chuck_hines_at_vnet.ibm.com>
IBM Logic Synthesis developer [BooleDozer (TM)]
and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]
IBM Internal email: hines_at_loki.pok.ibm.com,
HINESC at FISHKILL, HINESC at FSHVMFK1
"I have a paper plate in my head because they were all out of the metal ones"
- Rick Overton
*******************************************************************************
--
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 Fri Oct 27 1995 - 14:26:52 GMT