Subject: Re: FVWM: FvwmButtons bug (and workaround :-)

From: [email-masked] (Albrecht Kadlec)
Date: Mon, 2 Sep 96 10:12:55 +0200

>>>>> Guenther Grau writes:

G> 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.

G> Hmm, good idea, but I just tested (again, just to be sure I am not
G> telling nonsense :-) that this is not the case. I just started xclock&
G> in a shell, then did a restart fvwm2 and the FvwMButtons module comes up
G> again with the place for the clock reserved, but empty. An xclock comes
G> up as well. Then I wait until everything has settled down. After that I
G> execute xclock & in my shell, but it doesn't get swallowed. I guess that
G> when the option "UseOld" is not present, then it doesn't use old and new
G> ones :-) If it were a race condition it should swallow the newly created
G> xclock, which it doesn't.

right. the test above just rules that one out.
sorry, don't know the code, so I won't guess further.

only thing I can say is, that I had the problem that before I got UseOld to
work (ca. 0.39-41), every restart created new xclocks & xbiffs.
The old ones were _not_ mapped (also missing from the winlist, but still
running - ps x showed them), so that was somewhat different.
I don't think this is related, but I'm certainly not sure.

cheers,
albrecht
-- 
Maybe I'm paranoid, but remember, even paranoids have enemies.
					-- Cal Pryluck, Temple University
--
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].