Hi there.
I've seen the same thing on Solaris 2.5 (X11R6.1) and Linux 1.3.something
(X11R6): When I use xsm to start some clients (of which fvwm2 is the
last) they dont get properties (colors, buttons...) on their windowframes
that i`ve specified in my .fvwm2rc.
BTW: I use FvwmM4 too.
Speaking of FvwmM4:
Some time ago i posted something about a possible bug in fvwm2 with m4,
but nobody replied so i try again.
The thing is: FvwmPager behaves different when i use FvwmM4 (or FvwmCpp)
to process .fvwm2rc than it does when i just load in .fvwm2rc. When
i use a preprocessor the pager doesn't "flip" to the next page when i
move the mouse to the edge of the screen as it does when i dont use a
preprocessor. I have made i minimal config-file that exhibits this
strange behavior:
--------------------test.fvwm2rc--------------------------
# This enables paging when called with:
# fvwm2 -f "Read /home/stefh/test.fvwm2rc"
# But *not* when preprocessed:
# fvwm2 -f "FvwmM4 /home/stefh/test.fvwm2rc"
# fvwm2 -f "FvwmM4 /home/stefh/test.fvwm2rc"
DeskTopSize 2x2
AddToFunc "InitFunction" "I" Module FvwmPager 0 0
----------------------------------------------------------
Would someone please try this out to see if i'm just an idiot or if there
really is something wrong! (of course i have checked that the
preprocessors dont change the config-file before passing it to fvwm2)
I have seen this ever since my first fvwm2 (which i think was .39)
Keep up the (otherwise) _great_ work,
--------------
Steffen Hansen |
email: stefh_at_dit.ou.dk, stefh_at_imada.ou.dk |1 + 1 = 3, for large values of 1
URL:
http://www.dit.ou.dk/~stefh |
On Tue, 28 May 1996, Dan Calle wrote:
> 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.
>
--
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 Wed May 29 1996 - 13:43:03 BST