Subject: PipeRead vs. FvwmM4

From: Matthias Clasen <[email-masked]>
Date: Wed, 10 Feb 1999 22:01:51 +0100

Didn't someone ask for good examples showing how far fvwm 2.2
is superior to fvwm 2.0 ?

Here is one: PipeRead does not only obsolete FvwmM4 and FvwmCpp,
it is also more correct.

It always struck me as odd that on RedHat systems, the fvwm decorations
of clients started via Xclients don't obey the Style commands in the
config files. Today, it occcurred to me why this is: RedHat starts
fvwm2 via fvwm2 -cmd 'FvwmM4 $RCFILE'. fvwm2 doesn't wait for Fvwm4
to finish and enters StartupStuff which decorates the early clients
with the default decorations.

Another easy way to see this behaviour is to change the RedHat setup
to call fvwm2 without -cmd and create an .fvwm2rc like this:

##### start of .fvwm2rc #####
# read RedHat's default fvwm2 config. This defines eg the Window-Ops menu
FvwmM4 /etc/X11/AnotherLevel/fvwm2rc.m4

# Append something to the Window-Ops menu
AddToMenu Window-Ops
+ Shade/Unshade WindowShade

##### end of .fvwm2rc #####

And be surprised that "Shade/Unshade" ends up as the *first* entry
in the Window-Ops menu.

My first try to improve the behaviour was to use the Wait command to
wait for a client which is started in the config file parsed by FvwmM4.
This didn't work...for some reason, fvwm2 waited forever.

A much better way to use macros in config files is imho

PipeRead "m4 -DWIDTH=1024 \
             -DHEIGHT=768 \
             -DUSER=clasen \
             -DHOME=/home/clasen \
             /etc/X11/AnotherLevel/fvwm2rc.m4"

(The -D options turned out to be necessary, since FvwmM4 predefines
some m4-macros on which the AnotherLevel files depend.)

I'm convinced now that the preprocessor modules should be considered
obsolete and that PipeRead is the better alternative to be advertised.

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Phipps <[email-masked]>
Date: Thu, 11 Feb 1999 11:25:20 +0000

> Here is one: PipeRead does not only obsolete FvwmM4 and FvwmCpp,

Fvwm{Cpp,M4} have extra things defined for convenience that "PipeRead
cpp file"
wouldn't get so it doesn't obsolete them by itself.

> with the default decorations.

This is due to a bug in the way fvwm starts up. It waits for the first
read/readpipe to complete before doing the first capture.  This is wrong
when there is more than one read specified on the command line.  There
is a bug report for it, I forget the number. I have a patch but it's a
bit wacky so I won't post it until after 2.2.

> This didn't work...for some reason, fvwm2 waited forever.

You get a hang here because fvwm is not processing events yet and
clients don't get mapped without fvwm processing the create-window
events.  The client hangs in XCreateWindow() and the Wait never
completes.  The big problem with PipeRead is that it stops fvwm
processing events until the process on the other end of the pipe exits. 
If the PipeRead process tries to open a window it will hang itself and
fvwm. It's a Catch 22 situation, you can't have the advantage of
PipeRead input taking effect immediately without the danger of hanging,
the same goes with trying to get Exec to wait for completion before
doing the next line of a function.

> some m4-macros on which the AnotherLevel files depend.)
This is still vulnerable to the start up bug.  Try 

fvwm2 -cmd "Read /dev/null" -cmd 'PipeRead "m4 whatever"'

The initial capture will happen before the PipeRead even starts.

Cheers,
Tim.