Subject: Re: Q - fvwm-2.3.8

From: Dan Espen <[email-masked]>
Date: Thu, 07 Oct 1999 17:58:23 -0400

Nadim Saeed <[email-masked]> writes:
...
> Point well made.  A couple of minor things (if I'm out of line - in other
> words, the discussion has been had and that's that - let me know)
> 
> Concerning obsoleted modules:
> a. Instead of having links from FvwmAudio to FvwmEvent wouldn't it be cleaner
>    if fvwm internally reverted to FvwmEvent whenever FvwmAudio is called (this
>    support would disappear after the next release of course -- you don't want
>    these things to build-up -- you want the users to make the changes ASAP,
>    but yet be nice enough to accept their configs for _now_)

I guess you prefer the FvwmCascade approach where it constantly nags you
to change your config file.

If I remember right, I went with a shell that didn't nag.  Someone else came
up with the link.  My own opinion is that I see no problem with the shell/link
staying in place for as long as people still use fvwm.  Especially the link
since it takes almost no space at all.

In my own site, I have fvwm users that are unable to navigate vi, let alone
modify their .fvwm2rc.  Maybe that explains why I'd rather fvwm go overboard
with backward support.

How can extra code in fvwm be cleaner than a nice tidy link?

> b. As for FvwmTile (and FvwmTalk etc.) you don't necessarily have to create
>    those scripts as part of the 'make install'.  Those scripts could reside as
>    is in the distribution.  In other words, in the 'modules' sub-dir have a
>    directory named 'FvwmTile' with FvwmTile (the script) as its only content
>    (that way you are NOT dependent on "make install")

Yes, but "make install" is necessary, as you discovered.

The other advantage to the logic in the makefile is that when the
"nag interface" is finally removed, CVS won't have one of those deleted
files sitting around causing trouble in the attic.

> c. Cry foul (ie. print out an ERROR) and tell the user that FvwmAudio is
>    obsolete and tell them to use FvwmEvent instead (applies to all obsoleted
>    modules).

Well,  there is some of that  now, and I'm  against it.  Not enough to
complain about it,  but  I just wouldn't   do it myself.  I   view the
computer as the slave, the user is  the master.  The slave should not
tell the master to change his ways.

Some of the other developers must feel differently, perhaps when they
see my response, you'll get your wish.

> d. You'd mentioned something about a sed script for ImagePath (that script
>    could apply here as well to make the necessary changes).  Something along
>    the lines of 'convert_2.2_to_2.4' sed or perl script would do.

Yes I did.  I fully expect to write it before I install 2.4.  Did I imply
that this script would be generic?

Somehow I don't think so.  Take this example, my current settings:

PixmapPath	/u/dane/icons:\
/u/dane/public_html/textures:\
/opt/public/bin/rxvt-pixmap/textures/:$FVWMICONS:$SYSICONS
IconPath   /u/dane/icons:$SYSICONS:/usr/WI/include/X11/bitmaps

My new settings will probably be

ImagePath /u/dane/icons:/u/dane/public_html/textures:+

I'll build the rest of the icon directories into fvwm.

The hard part will be the other users.  Fortunately, the fvwm2 startup shell that
I use tracks userids.  I expect I'll look at every users .fvwm2rc and build a shell
to deal with all the variations.

See why I prefer that fvwm wouldn't complain about PixmapPath and IconPath?

> Concerning point-A above, I'd guess that fvwm does not get involved with
> modules, it just passes the calls, but the translation would be pretty light
> weight I'd think.  Point-B, I think, is clearer compared to what we have now
> with no added expense.  Point-C is already happening and Point-D would be
> pretty simple as well (whatever changes are needed to circumvent the obsolete
> modules would happen automatically for the user - similar to the convert
> fvwm1->2 script).

Hey, sorry, looks like I disagreed with you on every point.

I, for one, still appreciate your opinions.

> Am I completely whacked-out ?

Well, thats a question I don't know the answer to...yet.  :)

>  - Nadim (please cc replies)

Yep, still doing that.

> --

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 8 Oct 1999 02:40:38 +0200

> since it takes almost no space at all.

I agree that a link is the best solution and I don't mind if it stays
in place forever.  But I see the nagging more as a friendly reminder
that one day in the future things might not work anymore.  It's only
fair to inform people that some aspects of their config file are not
supported in the future (i.e. it may still work, but if there is a
problem we may tell them to do it differently).

> How can extra code in fvwm be cleaner than a nice tidy link?

It can't :-) But there alread *is* extra code in FvwmEvent to support
the old FvwmAudio syntax.  Not much, but still.

> see my response, you'll get your wish.

I see a difference between these shell scripts and changes like
the FvwmButtons panel rewrite or the GlobalOpts command.  Shell
scripts don't cost you much.  They are small and easily written
and maintained.  Features such as the old panels can be extremely
complex and prevent further development.  In such cases I am
willing to break backwards compatibility and confront the user
with warnings.  I wouldn't want to deny us the chance of making
progress, but still take great pains to keep backwards compatibility
where it is possible.  Shell scripts should definitely not issue a
warning.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [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]

---

From: Dan Espen <[email-masked]>
Date: Fri, 08 Oct 1999 09:25:49 -0400

> where it is possible.  Shell scripts should definitely not issue a

Sounds like we agree completely.

If you feel that way, the warnings in FvwmTile and FvwmCascade should
go away.

Those 2 shells will only go away if we make them go away.  I don't see
any pressing reason why they should go away either.