Subject: FVWM: FvwmM4 and FvwmCPP

From: "Christopher A. Smith" <[email-masked]>
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 * [email-masked]
--
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].

---

From: [email-masked] (Jon Mountjoy)
Date: Fri, 17 Nov 1995 15:42:58 +0100 (MET)

Hello,

Quoting Christopher A. Smith,

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

Well I have such a setup for my Solaris/SunOs boxes.  
It works just fine, except for the string of command line options needed in
my Solaris startup because the cpp is in a non-standard place and the makefile
didn't figure it out/isn't setup to figure it out?.

Here is the .fvwmrc clip:

#ifdef SOLARIS
ModulePath /home/jon/Fvwm/solaris/
#else
ModulePath /home/jon/Fvwm/sunos/
#endif

and here is a bit from my .xinitrc:

if [ x$sysv = xYES ]
then
 # SOLARIS
 Fvwm/solaris/fvwm -f "/home/jon/Fvwm/solaris/FvwmCpp -Cppprog /usr/ccs/lib/cpp
 -Cppopt -DSOLARIS /home/jon/.fvwm2rc"
else
 # SUNOS
 Fvwm/sunos/fvwm -f "/home/jon/Fvwm/sunos/FvwmCpp /home/jon/.fvwm2rc"
fi

Jon

---

From: [email-masked] (Mark Borges)
Date: Fri, 17 Nov 1995 10:37:08 -0700

>> On Fri, 17 Nov 1995 09:11:40 -0500 (EST),
>> Christopher A Smith(C) wrote:

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

I've seen something similar when restarting fvwm -- perhaps that bug
is related to this one.

Anyway, in my .fvwmrc I have lines like

	# Font selection -- can be conditionalized via CPP or M4.
	#FvwmM4 -m4-prefix ".fvwm/fonts-m4"
	#Read ".fvwm/fonts"
	FvwmCpp ".fvwm/fonts-cpp"

and that works fine (fonts-cpp is appended below). Maybe you can
strucuture your .fvwmrc to work around this bug. Personally, I like
having a .fvwm directory, with files categorized by function within
it, but I know some don't care for it.

  -mb-

/*
	Window and icon fonts
*/

#if Y_RESOLUTION >= 3700
#define WINDOWFONT	-adobe-times-bold-r-*-*-18-*-*-*-*-*-*-*
#define ICONFONT	-adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*
#else
#define WINDOWFONT	-adobe-times-bold-r-*-*-16-*-*-*-*-*-*-*
#define ICONFONT	-adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*
#endif

WindowFont	WINDOWFONT
IconFont	ICONFONT