Subject: Re: Why development spinoffs?

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 11 Dec 1997 17:45:16 EST

Hi people,

I'm not on this mailing list, but I'm the guy who originally started
scwm. I read the list archive and noted that some people have been
wondering why I split off development effort rather than trying to do
the same thing in the context of fvwm development. The were a couple
of reasons.

* When I started scwm, I had no clue about window managers or even X11
programming in general. I also didn't have any real experience working
on internet-wide projects of that kind of scale. I figured it would be
pretty arrogant to pop up on the fvwm lists out of nowhere and say "I
have this cool idea, how about using it for fvwm3?" I figured people
would rightly tell me to put some code where my mouth was, so I just
went off and started working on a prototype of my ideas. Greg said
that scwm has been in development for three months, but that's not
entirely accurate. I actually started working on it sometime last may,
but it took me a long time to get up to speed with the fvwm code and
with the guile library, as witnessed by the long time before scwm 0.0
came out.

* I thought that fvwm had pretty different goals than I did when I was
starting out. This may have been a misunderstanding of the fvwm
developer community on my part, but it was my distinct impression that
minimal system overhead was a relatively high priority, and I wasn't
sure at the time what effect replacing the fvwm configuration language
with Guile Scheme would have on that. Also I thought that since fvwm
was already much more widely deployed, people would be much more
suspicious of my dynamic loading ideas, since that wouldn't be
feasible on many older systems. Overall, I had the impression that as
compared to the fvwm community, I was more interested in features
relative to resource consumption.

So in summary, I never in my wildest dreams imagined that anyone would
possibly want what I was working on to be fvwm3 or such. I'm actually
flattered that anyone at all thinks that would be a reasonable
idea. 'mnot unreasonably attached to the name "scwm", but I am, at
this point, attached to maintaining a fair degree of control over the
source at least until the basic architecture is fully in place. The
latter would probably be more of a hindrance than the former to scwm
being fvwm3 I suspect. However, I definitely welcome fvwm developers
to take a look at the source and if they like what they see so far,
contribute code or just test things out.

Finally, a word on why I used Guile as the configuration language
rather than abstracting configurability out in some way: doing such a
thing would have complicated the implementation immensely. 

* One of the biggest motivations for me for starting scwm was the desire
to be able to connect complicated code wirtten in the configuration
language for callbacks. Making that work reasonably with one real
language is hard enough; doing it generically so that any language can
be plugged in is, I'm convinced, near impossible. Callbacks would have
to be represented by some C data structure that would abstract out the
difference between code for the various langauges, the differing and
possibly incompatible garbage collection needs of many langauages
would have to be dealt with in a generic way, and the differing
language concepts of a datatype (from Java's strong typing to Scheme's
dynamic typing to Tcl's "everything is a string" type system) would
all have to be accomodated. 

* Guile will supposedly eventually support multiple languages through
translation. Currently this is vaporware, but since RMS seems to be
sufficiently obsessed with the concept, I believe it will happen in
time. So this way I'd get support for other languages for free without
having to go through the pain outlined above.

I anyone wants to ccontinue the discussion, please cc me, since I'm
not on the fvwm-workers list.

 - Maciej Stachowiak

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