>>>>> 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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Sep 02 1996 - 03:22:04 BST