Subject: Re: Fvwm and Scwm

From: Dan Espen <[email-masked]>
Date: Wed, 15 Jul 1998 20:38:43 -0400

During the last go-around on this, the "add one million bytes" issue
seemed like a show-stopper to me.

I did take the time to download Scwm and was impressed by how clean
the config files looked when XEmacs could fully understand them and
highlight them accordingly.

However  as I looked through the  config files  is  wasn't clear to me
what I would do with this new, more flexible language.  As I use fvwm2
now, I don't  use FvwmCpp, FvwmM4, or  FvwmPipe.  I support fvwm2  for
over 20 users,  and none of  them report the  need  for a more  robust
config language either.

Along the  same line, as we  get fvwm2 users  problem reports, I don't
recall hearing problems that made me think, "if  only fvwm2 had a more
robust configuration language...".

I have  a hint what  most users want  is a GUI of  some sort that will
magically  configure menus for new remote  systems to start Xterms on,
and the like.  It isn't clear to me that cleaning up the configuration
language will make fvwm2 more amenable to GUI configuration.

I  do make  extensive  use  of  fvwm2  macros.  Even  though the macro
facility is primitive, it hasn't let me down yet.

If, through some  magic,  all fvwm2 development  ground to  a halt, my
first inclination  would be to say fvwm2  is good enough.  To convince
me to switch I would need:

  a foolproof way to convert .fvwm2rc files to Scwm config files (Note
that the current fvwm1 to fvwm2 conversion tool is far from foolproof)

  a fully documented Scwm

  all current fvwm2 modules working

  something compelling in Scwm that I can't get from fvwm2

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Greg Badros <[email-masked]>
Date: 15 Jul 1998 17:57:36 -0700

Dan Espen <[email-masked]> writes:

<snip>

>   something compelling in Scwm that I can't get from fvwm2

Thanks for this list.  Your perspective is appreciated.  There are
probably some features people have in their .scwmrc's that you'd really
like if you knew about them.  We definitely need a list of nifty things
people have done with Scwm -- the most recent that jumps to mind is
using our window-style's other-proc feature to customize the placement
of windows that meet a specific criteria -- e.g., making netscape's
popup windows go to a specific place (with all the power of scheme to
describe that place).

Again, thanks for your input.

Greg

---

From: Bob Woodside <[email-masked]>
Date: Thu, 16 Jul 1998 19:24:16 -0400 (EDT)

On 16-Jul-98 Greg Badros wrote:

> ...nifty things people have done with Scwm -- the most recent that jumps
> to mind is using our window-style's other-proc feature to customize the
> placement of windows that meet a specific criteria -- e.g., making netscape's
> popup windows go to a specific place...

        I've not had time to look into other-proc, but this funcionality has
been available to Fvwm2 users for nearly a year with my StartsOnPage patch.
It's been floating around in Limbo, because Chuck didn't have the time to work
it into a release, but a number of users are quite addicted to the feature.

        But I digress....

        My main reservation about a merger of Scwm and Fvwm is the same
one voiced by Chuck in his parting comments. I think there's a need
for a WM with the capabilities of Fvwm that is stand-alone, not
requiring other large packages to be installed. (I think the cross-
package dependencies are more the issue than the memory/disk footprint.)

        I have both Fvwm and Scwm installed on my personal machine at
home - indeed, I have most of the WM's currently in popular use, and
actually use most of them from time to time - but I might not have
the option of installing Scwm, Guile, et. al. on certain machines at
work, whereas the current Fvwm would be no problem. (If this scenario
sounds familiar to anyone, please speak up!)

        From my own experience, I'd have to agree with Dan's 
observation: I've not felt the need for a "more powerful" configuration
language. However, to play devil's advocate for a moment, I'll concede
a major benefit to be derived from plugging in a "standard" language -
consistency. This is because the existing configuration "language" is 
subject to the whims/inexperience/personality-quirks/whatever of 
whoever is patching in a new primitive when it comes to syntax and 
parsing. This could definitely stand improving.

        I think that the only way a merger can satisfy the needs of
both the self-contained and the extensible-WM camps is with a 
restructuring of the WM into a configuration layer and a core layer,
such that the configuration layer is effectively a plug-in, and does
*not* creep into the core layer. A rigorous layer separation with 
well-defined interface points should allow the core layer to serve 
as a common WM-engine - almost like a toolkit, actually - that could
serve to build both an Scwm and a  conventional guileless Fvwm (with
its existing, though doubtless much-modified, config layer). 

        I know you're going to object that there are certain "core" 
functions that could be better handled in Scheme - and you're probably 
right, but we might want to consider whether that implies that they 
shouldn't really be considered part of the core layer. Also, I don't
suggest that it should be illegal to override a core primitive function
with an extension ("hey, override that core method, Greg, the original 
code really sucks!").

        I may be pipe-dreaming - the two code bases may already have
diverged far enough that this approach is no longer practical - I 
haven't had time to look over the Scwm code in enough detail to judge.
Or, there may not be enough people who agree with this idea. But it'd
sure be nice to have a common base so that both groups wouldn't 
constantly need to be reinventing the others' wheels - like the Great
Style Flag Rewrite, which has long since been done for Scwm.

        Now...time to wade through today's mail and see where this 
thread's gone while I was at work.

---

From: Greg Badros <[email-masked]>
Date: 16 Jul 1998 16:55:05 -0700

> it into a release, but a number of users are quite addicted to the feature.

It's obviously a ton more general than that.  We've not yet even begun
to scratch the surface of what you can do with our primitives and
infrastructure.

One other remark -- one shouldn't look at guile as just a configuration
language in the same sense as fvwm's language is a configuration
language.  SCWM is exceedingly dynamic, and gets that in part from using
guile.

<good points and thoughts elided>

Greg

---

From: Bob Woodside <[email-masked]>
Date: Thu, 16 Jul 1998 22:31:18 -0400 (EDT)

On 16-Jul-98 Greg Badros wrote:

> -- one shouldn't look at guile as just a configuration language in the
> same sense as fvwm's language is a configuration language....

        Well, I just fell into using the same term several others have
bandied about, but you're quite right, it's a good deal more. Actually,
even Fvwm's is. What I was describing as the "config" layer is really
more like the command layer, including both the configurational and 
operational directives: relatively static in the case of the present
Fvwm, very fluid in the Scwm implementation.