Subject: Fvwm and scwm

From: Brady Montz <[email-masked]>
Date: 16 Jul 1998 10:24:16 -0700

First comment: this discussion seems to be humming along nicely. However, I
suspect that the anti-extension language people are holding back. Either that, 
orall of the people that responded to my posts on this subject a few months
ago are all on vacation.

Back before I became fvwm maintainer, I sent mail to the scwm people
suggesting the exploration of essentially make scwm fvwm3. I still think that
this might be a good idea, and would even be willing to give up head dude
status (I admit, once I became maintainer, my natural human instinct to
maintain posession reared itself).

However, my private feelings in support of (a) adding an extension language to 
fvwm, (b) that this language be scheme, and (c) rewriting large chunks of fvwm 
are merely my feelings. Before I became maintainer I did some hard lobbying in 
support of an extension language. At the current time, I feel that taking such 
a stance would be irresponsible. 

I suspect there is a huge segment of fvwm users who are quietly using fvwm
without using a large fraction of its current features, and who are either not
watching this discussion, or are watching it with the quiet horror akin to
that some have towards emacs. Fvwm is first and foremost a unix window
manager, and has reached its current level of success by sticking to the
philosphy common to many unix applications: small, fast, configurable, and
easy for a single programmer with no connections to improve. 

Here is my advice:

Fvwm in its current form will not last. The source code I have on my pc at
home, and the patches I keep receiving, are for a program which is not filling
a well-defined role. It is becoming too big and complicated to make the
minimalists comfortable, and it is not extensible enough to please the
"extension language" people. If I were to pick an analogy, I would compare it
to the vim project. I love vim and use it every day, but if I want to edit
something with graphical windows and fonts and make complex macros, I just use
emacs, not some vi clone that's been hacked up with python, perl, motif, etc.

I see three potential directions, each worthy of discussion:

1. Return fvwm to its roots, rewrite it, strip it down, and either find a way
   to move all of the extra functionality people have been grafting on it into
   modules or just get rid of them. People supporting this will have to make a 
   case that such a program will survive, stay supported, and not disappear
   and strand its users.

2. Find a way to balance the needs of the minimalists and maximalists. I don't 
   personally know of a program which has truly done this (although vim
   actually has done a good job, since I can turn off everything I don't want, 
   so I still like vim - no hard feelings), but it can probably be done "good
   enough." I suspect this will involve taking large portions of scwm, but
   being able to compile both fvwm and fvwm-lite. People supporting this have
   to demonstrate that it can be done.

3. State the memory is cheap, people who don't upgrade their hardware probably
   don't upgrade their software, and keep expanding fvwm. While the scwm
   binary is efficient, and small, I suspect that it will go a similar path to
   other such programs with users needing increasingly large amounts of scheme
   code installed somewhere to get what they want. People arguing this case
   have to demonstrate that while (probably) nobody uses the complete feature
   set of fvwm 2.0.46, every piece of it is used by lots of people and that
   going to an extension language is the most efficient way for everybody to
   get the pieces of this feature set they want. They also either have to get
   people to want to use scheme, and this is easier said than done, or
   convince them that they wil never have to touch any scheme.

I think that #2 may be the way to go. I think that scwm is a valuable project
to the Internet, and even if people don't use it, they will benefit from the
work that it does and inspires in spin off projects (particular other guile
projects). I also suspect that it may be hard for (some or most of) the scwm
people to "settle down" and make a stable version that their users like but
perhaps they don't. I also think that fvwm could use a lot of the stuff that
scwm is doing, so they should stay, at the very least, sister projects. 

I don't think people will ever agree on an extension language. Hell, the
xemacs people have been cutting themselves up over whether to use scheme or
common lisp. If you can't get people to agree on which dialect to use, its
unlikely to get people to settle on python vs scheme vs C vs ...

One approach which I would like to explore (those who've recoginized that I
work on the Scout project won't be surprised by this) is the option of turning 
fvwm into a window manager toolkit, from which managers of various complexity
could be written, but which would maintain compatability in the important
things (like the module interface). 

-- 
 Brady Montz
 [email-masked]
--
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: Michael M Han <[email-masked]>
Date: Thu, 16 Jul 1998 11:20:47 -0700

Whew, it's a good thing you're stepping back into the discussion since
folks are getting pretty ornery on this topic. My sense is that
consensus *can't* be found here, since it looks like the issue is
devolving into a question of religion.

But it seems to me it's about time some folks got alienated for good
though... Look, I don't see that it's feasible to keep fvwm a
RAM-consumption mouse *and* provide a well-designed option for a
turing-complete configuration language. I *could* see returning to the
earlier notion of extending the modules interface so an interpreter
could be made sufficiently functional as a module, but I don't think
*anyone* will be happy with that... No one will really grumble too
loudly, but no one will be happy either, I suspect. I really don't see
a good way to build a consensus here and a decision has to be made
here.

As far as fvwm's design and architecture, I haven't got a lot to say
since I'm far too unskilled to offer an intelligent opinion. But I am
curious to know:

    When we talk about embedding an interpreter in fvwm which is
    managing the configuration, are we saying that the same language
    will *also* provide the basis for writing extension modules? I.e.,
    will FvwmPager, for example, be entirely writable and runnable
    from what essentially used to be .fvwm2rc?
    
    I'm assuming that an implicit assumption of those who resist an
    embedded interpreter is that similar functionality could be done
    as a module, if the module interface were expanded/improved. What
    kind of impact would such an expansion/improvement have on fvwm's
    core's size? I don't expect anyone's saying that adding a proper
    interpreter *somewhere* is a Bad Thing, people just don't want it
    as the single-available option in the core...

I *will* comment that as a *non*-programmer, setting up my fvwm2 has
really seemed a lot like programming at times. *Especially* when
working with my modules configurations. It becomes the *most*
pronounced when I start thinking a cute little FvwmForm could solve a
little problem for me. FvwmForm basically exposes the XForm toolkit to
scripting through Fvwm's configuration language... This is an oddity
and really makes the division between programmable extension language
and configuration language blur and make me go dizzy...

I suppose that if one has to choose one of the extreme options (since
I don't expect any compromise is feasible) it's important to finally
decide what's fvwm's design principle. At heart, this discussion, it
seems to me, is about the question, "Is FVWM 1) a small, fast wm
foremost or 2) ultimately, a highly-configurable wm?" The trouble is
that proponents for each side see that there's already something quite
good at each end: twm on the one hand; scwm on the other...

Just some thoughts from a (not completely) satisfied fvwm2 user.
_________
mike ([email-masked])
I will not barf unless I'm sick
 - The collected wisdom of Bart Simpson
--
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: Jason L Tibbitts III <[email-masked]>
Date: 16 Jul 1998 14:08:14 -0500

>>>>> "BM" == Brady Montz <[email-masked]> writes:

BM> First comment: this discussion seems to be humming along
BM> nicely.

I will remind everyone to please make sure that <[email-masked]> gets a
copy; as a (the?) primary scwm author who is not a member of fvwm-workers,
he needs to see this discussion.

BM> However, my private feelings in support of (a) adding an extension
BM> language to fvwm, (b) that this language be scheme, and (c) rewriting
BM> large chunks of fvwm are merely my feelings.

I've seen some good arguments as to why it won't work to have the
configuration language be a module.  I've yet to see mention of the idea of
having more than one core (being the configuration language plus builtins)
and have everything else be modular (or in a shared library).  (In other
words, two essentially different window managers sharing a whole lot of
code.)

In the end, I'm really partial to saying that fvwm3 will be new and
different, while fvwm2 will continue to be supported in perpetuity.  That
ensures that "fvwm" (as a project) will still go somewhere, while fvwm2
stays small (because you can tell people to just use fvwm3 if they want
some particular feature).

I think, though, that for anything to be called fvwm3, it has to at least
try to stay true to what fvwm has always stood for.  It needs to be
functional (no argument about scwm here) and frugal.  Fortunately frugality
is relative; making it "small" should always be a goal, even if that means
telling people not to use some available features to save space.  It
doesn't have to be within some percentage of fvwm2's (or 1's) size, because
computers really have advanced and memory doesn't mean quite what it used
to.

BM> Fvwm in its current form will not last.

I agree.  It is being pulled in (at least) two directions and it's
impossible for a maintainer to just split the difference.  That's why
development usually splits in the first place.  (Well, that and stagnation,
but we seem to have fixed that lately.)  But instead of a complete split, I
think it would be worthwhile to have two programs, one oriented towards
features and another oriented towards size, both sharing as much code and
programming effort as possible.

BM> 2. Find a way to balance the needs of the minimalists and
BM> maximalists. I don't personally know of a program which has truly done
BM> this (although vim actually has done a good job, since I can turn off
BM> everything I don't want, so I still like vim - no hard feelings), but
BM> it can probably be done "good enough." I suspect this will involve
BM> taking large portions of scwm, but being able to compile both fvwm and
BM> fvwm-lite. People supporting this have to demonstrate that it can be
BM> done.

Can it be done?  I don't know.  We'd have to start by comparing
functionality and feature sets and see what can be put into libraries that
can be used by two different cores.  It is not a simple task.  (Both scwm
and fvwm would be better for it if it were done, though, even if nobody was
talking about a merge.)

 - J<

---

From: "Eric S. Raymond" <[email-masked]>
Date: Thu, 16 Jul 1998 16:12:35 -0400

Brady Montz <[email-masked]>:
> I think that #2 may be the way to go.

I think so, too.  As a person who's not in either the fvwm or scwm camps,
but who's been around the track a few times, I may have a strategy to suggest
for accomplishing it.  It'll take a little give and goodwill on both sides.

I can see a merge working given three commitments:

1. The scwm people must provide a fully capable .fvwm2rc-to-.scwmrc
   translator.

2. Scwm must support all existing fvwm2 modules.

3. The fvwm people must accept that for the first few releases (until
   guile gets space-tuned), the scwm/fvwm3 code may have a bigger footprint
   than the existing fvwm2.  

In other words: if the scwm people will live with a requirement that
scwm be painlessly upward-compatible with fvwm2, and the fvwm2 people
will cut them *temporary* slack on the footprint issue, we can all
make this work.

There's a reason I emphasize `temporary'.  We're talking about replacing
the ad-hoc config code with Guile.  A key advantage of this is that it
would allow fvwm to leverage lots more brains than just the fvwm workers.
Better dynamic-loading and modularization for Guile is critical-path
for lots of projects besides ours.  It's much more likely that Guile 
will improve dramatically than that we will ever get motivated enough to
clean up the ad-hoc cruft in fvwm2's present guts.

Eventually, here's what I hope we can all agree to deliver:  a version of
scwm that, when called through a link named fvwm2, reads .fvwm2rc,
translates it on the fly to Guile, and runs just like fvwm2 (modulo
bug fixes).

The program used for .fvwm2rc-to-Guile translation should, of course,
be available standalone for people who want to go pure Guile right away.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The only purpose for which power can be rightfully exercised over any
member of a civilized community, against his will, is to prevent harm
to others. His own good, either physical or moral, is not a sufficient
warrant
	-- John Stuart Mill, "On Liberty", 1859
--
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: Steve Robbins <[email-masked]>
Date: Fri, 17 Jul 1998 10:21:54 -0400 (EDT)

>    case that such a program will survive, stay supported, and not disappear

This option sounds good to me.  As everyone has observed: there is far too
much crud in the current sources. 

There were a couple of reasonable posts in the last 24 hours or so
advocating a cleaned-up core (preferrably in a shareable object) and
shoving all the "configuration" or "command" functionality into a second
layer built on top of the core. 

To my mind, it would be great if fvwm2 and scwm shared the same core.  I
can imagine having in the future, an fvwm2 binary linked to libfvwm, and
having an scwm binary linked to the *same* libfvwm, as well as to
libguile. 

Since the scwm folks have already gone through a "crud-reducing" phase
with fvwm sources, it would be nice to harness their expertise while doing
the same with the current fvwm sources.  There was one claim that they had
gotten the scwm binary down to 2/3 the fvwm2 size by cleaning up the code. 
I suggest that fvwm2 concentrate on the same task.  I realise that some of
the "savings" were derived from pushing the functionality into libguile,
and thus illusory.  Yet, it seems clear to me that there is much to gain
from a careful re-engineering of the sources.

To echo the point that grafting guile into fvwm was an impetus to cleaning
up the code: as I was trying to put the sources under autoconfigure, I had
to look at small bits of the sources.  I found some rather amazing coding
practices, such non-void functions that sometimes didn't return a value! 
(And yet, the return value was used by some of the function's callers)
There are many things that compiling with "gcc -Wall" would point out in a
millisecond.  I fixed the ones that I found, but the changes got lost as
the 2.0.47 versions were not based on the autoconfigured code.

Everyone agrees that scwm & guile are not stable enough for general usage. 
I can't see the gain in radically changing the direction and size of fvwm
to accommodate some alpha-quality interpreter.  I'm not interested in
claims that guile will be "lean and mean" at some unspecified time in the
future.  Such claims have to be viewed skeptically --- not that I doubt
the sincerity of the proponents, but what piece of software *ever* got
smaller? 

I do see gain in building a compact core of wm functions, to be used with
both fvwm2 or scwm.  Moreover, the process of teasing apart the "core" and
"command/configure" layers will be akin to what scwm did.  Hence, a
similar amount of cleanup and bugfixing should occur.

--
Steve Robbins                              <[email-masked]>

Istanbul was Constantinople,
now it's Istanbul, not Constantinople.
Why did Constantinople get the works?
That's nobody's business but the Turks'!