Subject: Re: Fvwm and Scwm

From: Tim Phipps <[email-masked]>
Date: Fri, 17 Jul 1998 09:08:20 +0100

OK folks, here's my take on this:

Lets get Fvwm2 out first.

Then we can each figure out wether to go with Fvwm or Scwm.  I don't
think Scwm should be renamed Fvwm3 it's just going to be too different. 
>From my perspective the config language is the main feature of a window
manager after all most of them can cope with moving and iconifying
windows, their strengths and weaknesses lie in the users ability to
control the way in which their windows work.  I moved to fvwm from
mwm/dtwm because I couldn't get them to manage the focus in the way I
wanted.  Fvwm is better but not exactly what I want. What I really want
is to be able is to be able to write high level code that can get at the
window manager's state and window lists.  I'll probably move to scwm
when I get the time.

Cheers,
Tim.
--
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: Maciej Stachowiak <[email-masked]>
Date: Fri, 17 Jul 1998 09:30:46 EDT

Seeing the number of messages in the fvwm mail archive this morning
that I didn't get, I've given up home on people cc-ing me, so I'm now
subbed to this list.

Brady Montz <[email-masked]> wrote:
>
> 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 like the vi vs. vim vs. emacs analogy. vi and emacs represent
opposite poles on the configurability vs. minimalism spectrum

> 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.
>

Reversing feature creep is very hard. At the very least, it is cruel
to tell people who like the new features (I'd suggest decors and
window shading are two examples of fairly grafted on features, and I
know that people do use them) that they are going away and the
featureful version will no longer be maintained.

> 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.
>

First off, I'd like to suggest that using Scheme is not so bad. On a
superficial level, you could easily write a scwmrc that would look
like an almost literal transliteration of an fvwmrc, with a pair of
parentheses around each line. For example, if I write:

(menu-style #:fg "white" #:bg "blueviolet" #:stipple "blue")
(menu-style #:font "-adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-*")

(title-style #:font font12 #:justify 'left)

(window-style "*" #:fg "white" #:bg "navy" #:icon "unknown1.xpm")
(window-style "*" #:border-width 6 #:focus 'mouse
              #:random-placement #t #:smart-placement #t)

(bind-mouse 'title 1 interactive-move) 

I think anyone familiar with the fvwmrc language will know exactly
what this means. In fact, I claim this is actually _more_ readable and
understadable than the fvwmrc equivalent. That could be just because
I've been smoking too much Scheme, but I don't think so.

Second, I think it is quite possible that the majority of people will
not need to touch Scheme. I have four reasons for saying this (2 of
which are our vaporware, and 1 of which is someone else's vaporware,
so apply the appropriate weighting factor to those):

* Many people don't really touch the fvwmrc language as it is. Mostly,
they take what they're given, possibly frobbing the colors and
key/mouse bindings by finding where they are in the file and replacing
them.

* I believe it is possible to write an on the fly fvwmrc translator so
you can just write an fvwmrc in the fvwm2 format, possibly with some
extensions and have access to extra features. Right now, the focus is
on a one-time translator, but I'm perfectly willing to look into an
on-the-fly version if there is a lot of demand.

* We plan to have a GUI configuration that will let users set things
like visual appearance and mouse and key bindings without having to
touch _any_ config files. As soon as we have loadable Gtk and/or Tk
support in the config file (I'm working on both), this should be
pretty easy.

* Guile wants to ultimately be a multi-langauge extension language
through the use of translators. There is already a language with a
C-like syntax that users can use, although with some hassle. When it
stabilizes a bit more, we will start providing example scwmrcs in the
C-syntax format to ensure that this functionality works and is
convenient with scwm. The same will be done for other language
translators that become avialable (Perl, Python, Tcl and emacs-lisp
are among those planned). 

Some people may claim translators for real languages will never
happen, or that when they do they will be unacceptably slow. As to the
first point, I think it underestimates the tenacity of GNU hackers. In
fact, I will personally work on a Tcl translator if I don't see one
otherwise happen fast enough. As for the second, someone has already
written a version of Tcl that translates to a different dialect of
Scheme which runs faster than the original Tcl. Python is also not
exactly a super-fast language as is either. Perl is fairly fast, but I
think it is possible to come within 2x for most tasks through
translation. It will probably be necessary to steal the existing Perl
parser for this, though, as I don't believe the Perl syntax is well
enough specifi{ed,able} for an independent reimplementation.

I'd also like to suggest an option #4, which has some elements of both
#2 and #3 above.  This is to continue to maintain fvwm2 well after the
first official stable release is out, perhaps effectively in
perpetuity, and at some point also begin work on an fvwm 3.x that has
an extension language. This is for the moment putting aside concerns
about _which_ extension language (though I clearly have a personal
preference).

> 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 disagree with this assertion. I think the time when we "settle down"
as you put it is perhaps some time off, since there are a number of
facilities we want to reorganize before we will feel comfortable
enough with the extension interface's stability to call a release
"1.0". But once that time arrives, I think we will be prepared to step
back and examine what needs to be in the release, and to seriously
consider backward compatability when making changes. Indeed, probably
_the_ major reason we have been in pre-releases for some time, and
will probably continue to be for some time, is that this way, we feel
no moral imperative to be backwards-compatible with old releases. This
is crucial because we _know_ some of the APIs as they stand are just
not right.

In any case, I think comparisons to the Gimp might be appropriate. For
a long time people thought that there'd never be a Gimp 1.0 and that
if there were, it would ccontinue to be a fairly crashy program with a
rapidly changing feature set and interface, and a host of possibly
broken extensions. But the Gimp team proved as capable of stabilizing
the program's interface, fixing the major bugs, and removing the
extensions that were just not ready for prime time, and came out with
a very nice release indeed, even if it took them a while.

I think the same thing will happen with scwm, whether or not a merge
with fvwm happens.

> 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 agree with that in principle, although actual literal code migration
is becoming more and more non-trivial.

> 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 ...

Oddly enough, the one category of post I have not seen yet (maybe
because I haven't read all of yesterday's mail on the archive yet) is
"I do want an extension language but not Scheme, anything but Scheme!"

This is especially odd, because these are the people I most wanted to
hear from, to see if there was a way to deal with their concerns.

> One approach which I would like to expl (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).

The important and useful code in fvwm is, IMO, the large library of
window management builtins, along with the code that manages the basic
window data structures. As fvwm now stands, this code is not very easy
to reuse - each builtin takes the rest of the line it was on as a
string and does the parsing itself. Scwm has managed to separate the
parsing from the builtins themselves, but it's made everything
dependent on Guile's data types instead.

The module interface is somewhat less important when you have an
extension language, and it can also reasonably be implemented _in_ the
extension language itself (which is what we have for scwm). OTOH, it
would certainly be useful for window managers that differ only on look
& feel but have no real extension language to be able to share modules.

 - Maciej

---

From: Nadim Saeed <[email-masked]>
Date: Fri, 17 Jul 1998 15:01:31 -0700 (XXX)

It sounds to me as though most of the discussion is really concentrated on
a couple of points,

 1. Since to some it sounds like SCWM is the future of where FVWM ought to
    be headed, the SCWM guys (with some FVWM blessing) have been asked to
    come on the mailing list and make their case

 2. The concerns that have been noted are
    a. RAM  memory footprint
    b. disk memory footprint
    c. ease of coding (extensibility)
    d. cleaner interface (primitives)
    e. usefulness ?

Let me first start by saying that I am an avid Fvwm-1/2 user and have been for
the past 3-4 years.  I love Fvwm, but lack the necessary C-skills (and time)
to really delve into the code (alas, I've made suggestions in the past, asked
questions, assisted a few people, etc) -- I keep up by reading the archives on
an almost daily basis.

So I'm your typical user that wants to be involved, but stays in the shadows.

Let me address each point noted above separately (for whatever that's worth)

 1.  I don't have a problem with this point

 2a. Fvwm has _always_ prided itself on having a really small RAM footprint
     (regardless of RAM cost :-) and that is really important to alot of
     people (it usually translates to speed, etc).  The SCWMers have noted
     that Guile is in needed fat as is SCWM code TODAY and that they are
     willing to do their part to slim it down.  Guile is planned to slim
     a bit (I wouldn't hold my breath, but at least the issue is on the
     table).
  b. This really shouldn't be of much concern since we are talking about
     Kbytes that don't amount to much anyway.
  c.
  d. SCWMer have repeatedly expressed that they have a cleaner framework in
     place which certainly leads to cleaner/easier code - I'm not about to
     refute any of this since I haven't delved into the code in any great
     lengths (but what I've seen seems the to be the definition of ad-hoc).
     It sounds as though one will have a greater deal of control of the
     interworking of the WM with a more robust config language (again I
     don't know anything about Guile)
  e. Ah, the clincher !!  Is this at all useful or is it just plain 'old
     COOL to do ?  Now, I haven't really read anyone say anything that made
     me go "wow, that would be nice to do, but damn it Fvwm doesn't allow me
     to do it".  To be open minded, we don't know what we (FVWMer users) are
     missing until we are told that one can do this, that and the other
     (that's when ideas and options seem to abound)

OK, what does this all mean.  From my prospective here's how I look at it,

1. Let's get Fvwm-2.1 OUT
2. Let's have "The Great Style Rewrite" done with
3. Let's restructure the WM into a configuration layer and a core layer
   (per Bob Woodside's <[email-masked]> suggestion)
4. Let's have the SCWM guys spend more time and effort on memory footprint
5. If scwm's (including Guile) footprint is acceptable AND it mimics _all_ of
   Fvwm functions AND its as fast as FVWM, then I think the decision would
   pretty simple :-)

Again, I might be naive in saying what I said or in over simplifying life, but
that's my take on this.

Questions/Requests:
  + Could an SCWMer post an example of their .scwmrc file (for comparison) ?
  + I'm curious about what SCWM can do today (or in the future) that wouldn't
    be possible under FVWM ?
  + One thing to note is, in what ways will the end-user have to adapt or
    change to start using SCWM (if it were to be fvwm3) ?

 - Nadim

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 17 Jul 1998 19:41:25 EDT

I don't think my first attempt to sub to this list worked, as I
haven't gotten a flood of mail from it (in fact, nothing). I just now
subbed again, and I think it worked this time. So I won't be seeing
today's earlier messages until tomorrow, in case anyone wonders about
any delay in responding.

 - Maciej