FVWM: FvwmM4 and FvwmCPP

From: Christopher A. Smith <casmith_at_clark.net>
Date: Fri, 17 Nov 1995 09:11:40 -0500 (EST)

'Twas curing a PCI 133 MHz Pentium with 24-bit color the other day of its
Windows 95 infestation by installing a useful operating system, Linxu
1.2.13, on it. Since I'd had no problems whatsoever with fvwm 1.x or 2.x
over the past couple of years on any of the platforms I'd used it on --
SunOS, Solaris, HP, AIX, or Linux -- I quickly installed fvwm 2.0.38,
which just screams on this system. After we beat NIS and token ring into
submission on it, I went through the task of configuring my .fvwmrc file
to support not only HP (my primary workstation at work), but also Linux,
Solaris, and AIX. I figured that this would be the perfect application
for FvwmM4, so I read up on them and went to work, modifying my .fvwmrc
and .xinitrc files appropriately. The only change I'd made to my .fvwmrc
file was to wrap the ModulePath with a test for the operating system type;
everything else in my .fvwmrc file was valid on all the other architectures
we use at work. The only change I put into my .xinitrc file was to tell
fvwm to run FvwmM4 at startup.

What I noticed was this: When starting fvwm, telling it to preprocess the
.fvwmrc with FvwmM4, the cosmetic configuration (borders, colors, etc.) was
completely wrong (default values, methinks), but when I ran the .fvwmrc
file generated by FvwmM4 through fvwm (i.e. fvwm -f "Read /tmp/fvwmrc..."
or something like that), everything came up fine. Pathnames to modules,
colors, borders, everything.

This also happened with FvwmCpp.

I got around the problem with a less optimal approach, but it worked: one
.fvwmrc file for each architecture. (To quote Tim Bray from OpenText
Corporation: "Disk space is free [after you factor in the costs of living
with disk space shortage.]") I really would like to get the FvwmM4 or
FvwmCpp approach working, though, because it is the more optimal answer to
this multi-architectural situation; unfortunately, I don't have the time to
give in to temptation and walk fvwm through the debugger to see what it's
doing. If anyone has any pointers on using FvwmM4 or FvwmCpp -- things to
watch for, do's-and-dont's, etc. -- I would really appreciate it!

                 --------------------------------------
                          Christopher A. Smith
                    Arlington VA * casmith_at_clark.net
--
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 Nov 17 1995 - 08:11:44 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:57 BST