Apologies if this bug is listed somewhere, I looked in all the usual
places and couldn't find it.
Background:
I run my initial X clients from my .xsession which is set
up thus: a bunch of random junk (X settings, variable settings, etc)
runs, some of it asynchronously, then an xterm runs asynchronously,
then a bunch of other X clients run, most of them asynchronously but
also mostly preceded by sleeps so that they don't slow down that first
xterm, and then finally fvwm2 runs, using FvwmM4 to process the rc
file.
Problem:
If I do something to take the xterm binary out of RAM and then log in,
running the .xsession described above, that first xterm will not get
*any* style attributes, not those specifically for xterms nor those
for "*". It's the wrong color, isn't SloppyFocused, the borders are
too thick, etc. Any other xterms, either the second one run from my
.xsession or those run from fvwm or a command line, get all the style
attributes correctly. And if I restart fvwm, the first one will
suddenly get all the right attributes. This makes me think it's a
timing problem related to the order the .xsession processes finish in.
If I log out and log back in, it doesn't happen again, presumably
because the xterm binary is still in RAM and runs faster next time
through the .xsession. But if I kill all my xterms, run a bunch of
Netscapes to eat up my RAM and thus take the xterm binary out of RAM,
and *then* log out and log back in, it happens again. Same thing if I
reboot, clearing RAM, and then log in.
OS: Digital UNIX 3.0 and 3.2a (tried on two machines)
X: X11R5
Fvwm: Version 2.0.42
Compiler: DEC OSF/1 C compiler 3.11 (comes with DU 3.0 and 3.2a)
Compiler opts:
Compiled "out of the box" from the instructions in INSTALL. That
means that the cc options (besides all the include and lib stuff) were
"-O2 -Olimit 2000". The only change I made was to set the bin and
module directories to be /usr/local/{bin,lib}/X11.
I'm only subscribed to fvwm-announce so if anyone wants more info,
please mail me.
Thanks.
PS - There's another bug, one that's been around since 1.24. I
mention briefly it here in a postscript 'cause I'm not sure if it
might be one of the mouse-related bugs listed in TO-DO. I think it
might be in FvwmAuto 'cause it went away when I used 1.24's built in
autoraise - something I obviously can't do with 2.0.x. But it seems
to be another timing problem so it could just be within the raise or
lower functions themselves. I'm not exactly sure what causes it but
it usually seems to happen when a window disappears quickly. Fvwm
gets stuck with the cursor in its intermediate form (the black, filled
circle) until I click somewhere. Until I do that, X and all my other
apps continue to run but fvwm is stopped.
--
Dan Calle SysAdmin and Research Assistant
Physics Department, Sweet Briar College
Email: calle96_at_sbc.edu Talk/Finger: dcalle_at_lucifer.gu.sbc.edu
Web Page: http://csugrad.cs.vt.edu/~dcalle/ Finger for PGP key.
--
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 Tue May 28 1996 - 18:43:10 BST