Albrecht Kadlec wrote:
> G> *FvwmButtons - whatever Swallow "XClock" Exec xclock&
>
> But I suspect a logical problem in the code. (simply a race condition):
>
> Maybe the clock appears too fast, since the code is already in core.
> I think, FvwmButtons looks for some sort of window creation event.
> If that one has already passed, it won't find the window.
Hmm, good idea, but I just tested (again, just to be sure I am not
telling nonsense :-) that this is not the case. I just started xclock&
in a shell, then did a restart fvwm2 and the FvwMButtons module comes up
again with the place for the clock reserved, but empty. An xclock comes
up as well. Then I wait until everything has settled down. After that I
execute xclock & in my shell, but it doesn't get swallowed. I guess that
when the option "UseOld" is not present, then it doesn't use old and new
ones :-) If it were a race condition it should swallow the newly created
xclock, which it doesn't.
Guenther
--
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 Fri Aug 30 1996 - 12:31:51 BST