Subject: Re: FvwmAudio is obsolete, right?

From: Dominik Vogt <[email-masked]>
Date: Wed, 5 May 1999 12:56:37 +0200

On Tue, May 04, 1999 at 11:09:15PM -0700, [email-masked] wrote:
> Previously...
> >> Finally, FvwmEvent still doen't handle PlayCmd properly. Cmd and
> >> PlayCmd are handled in the same case, which is fine, except that Cmd
> >> and PlayCmd work differently. PlayCmd expects an external binary to
> >> exec; Cmd expects an fvwm builtin. To make PlayCmd act properly, it's
> >> got to be preceded by an "Exec " or better yet "Exec exec ". Here's a
> >> patch that prepends that string to cmd_line when setting it from a
> >> PlayCmd directive:
> >
> >Yes, that was a conscious decision. Since applying the PlayDir to
> >the 'FvwmEventCmd' parameters does not make sense I made PlayCmd
> >a synonym to Cmd. When invoked in compatibility mode FvwmEvent
> >really works like FvwmAudio now. I think that is all right since
> >there can be only one cmd_line anyway.
> 
> I don't really understand. Without FvwmAudio, the user would get no
> FvwmAudio working, with a report that FvwmAudio doesn't exist. Some
> FAQ would indicate that FvwmEvent supercedes FvwmAudio. With an
> unchanged FvwmEvent symlinked for FvwmAudio, the user would get a
> broken FvwmAudio, b/c their config wouldn't be handled properly. With
> a broken PlayCmd in FvwmEvent as FvwmAudio, FvwmAudio remains broken,
> printing "could not find cmd_line in ModulePath foo" to fvwm's stderr.
> 
> The point, I thought, was to allow the silent removal of FvwmAudio and
> replacement with FvwmEvent, maybe printing warnings to stderr to the
> effect "This command is now deprecated, as FvwmAudio is dead. See
> FvwmEvent's man page." But this isn't accomplished unless PlayCmd
> works, since it's the crux of configuring FvwmAudio...
> 
> Maybe it's no big deal, but then I don't see any reason not to just
> yank FvwmAudio and write an FAQ entry stating that FvwmAudio users
> should look to FvwmEvent...

But why do you say FvwmEventPlayCmd does not work? When in compatibility
mode both, FvwmEventCmd and FvwmEventPlayCmd behave like the old
FvwmAudioPlayCmd. This means that FvwmEventCmd behaves differently in
compatibility mode that in normal mode, i.e. it runs shell commands like
FvwmAudio did, not fvwm functions.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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]