Subject: Re: Fvwm and Scwm

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Jul 1998 11:40:02 EDT

I don't subscribe to this list currently, and many people have been
replying on this thread without cc'ing me. I just read the list
archive, so I will respond to the messages here all at one go.

I saw several concerns from people who were opposed to the idea of an
fvwm/scwm merge, and I would like to clarify several of these points.

1) A number of people saw my message as an attempt to "hijack" fvwm
development, and read it as encouraging the fvwm developers to stop
work on fvwm2 immediately and bow down to me as lord and master of
window managers. That's not what I'm saying at all. 

* I don't believe fvwm2 development should stop now. Fvwm2 suits many
people's needs just fine, and it needs to be fixed up enough to be
released officially. Scwm is also not totally ready for prime time. It
is lacking (although we're actively working on it) good docs, an
fvwmrc->scwmrc translator, and a stabilization of the API provided to
the user by the config language before it could even be considered to
be as much of an end-user solution as fvwm.

* Some people want to use a real configuration in future versions of
fvwm. If this is a real goal shared by many people, I suggest
cooperation as opposed to reinvention of wheels.

* In fact, some people have suggested in the past that an fvwm/scwm
merge. At the time, it was unclear that this was feasible, or that it
was something any significant proportion of the fvwm community wanted.

* I am not trying to steal the fvwm name just to gain instant fame and
popularity. It is true that a larger base of users/developers would be
a great thing for scwm, but I would only want to pursue this if the
fvwm community feels they would also benefit from a merge.

2) Several people expressed concerns about the additional resource
consumption of embedding a real configuration language in a window
manager. In particular, brian moore <[email-masked]> had a lot to say
about this. He also mocked the idea of extension through dynamically
loaded code (.so files), citing WindowShade as an example of something
that was better off being right in the core.

* The cost in resources is not high, and is potentially negative
compared to what fvwm does now. Right now, scwm will use about 1.5 to
2 times the memory of fvwm with a typical config (i.e. about 1 meg
extra). However, scwm and guile are both at a point where essentially
no major work has been done to reduce memory consumption. Guile will
be split into a much smaller core, with much functionality split out
into loadable modules. The interpreter Guile ultimately traces it's
descent from, SIOD, provides just the code Scheme language and is
extremely small. I believe the Guile core will also be quite small
when Guile is more mature. The same will be done with scwm, in terms
of breaking out code into loadable modules. With scwm specifically,
there is the additional benefit that many Fvwm primitives are
redundant, or offer redundant optional functionality, when combined
with a real configuration language. Further, many Fvwm modules, which
incur the overhead of a whole separate process of compiled code, can
be replaced with a few lines of compact, interpreted scwm
configuration language code. Ulimately, I don't believe scwm will use
much more memory for comparable configs, and possibly will use
less. At the same time, it will allow you to do a lot more.

* The example brian cited with WindowShade is, IMO, a case where the
Fvwm code is broken. Maximize should not be checking whether a window
is shaded or not to see if it's OK to maximize it. One of these two
tracks should be taken: the core window data structure should have a
CannotMaximize flag which would be set by any window operation that
precludes maximizing the window; or, better yet, shading a maximized
window should work (it should just put the title bar in the size and
position it would be in if you'd maximized and then shaded, and set
the window so restoring it after shading and maximizing will
DTRT). The latter is the track we took with scwm. Following this
philosophy, WindowShade could reasonably be broken out of the core
into a loadable module

3) Some other people questioned wether there was any real benefit to
having a real configuration language. In particular, Dan Espen
<[email-masked]> mentioned that he'd never run into a problem he
thought could be solved better with a real configuration
language. Makoto MATSUSHITA <[email-masked]> expressed
the related sentiment that Fvwm made the right choice in providing
only a simple, low-level configuration language. He said that the use
of CPP or M4 as a higher-level language was a deliberate design
choice, commparing the built-in fvwm config language to x86 assembly.

* Here are several things we've done in Scwm so far that I believe
were enabled by having a real configuration language built-in:

** A number of primitives, and in some cases modules, could be
replaced by a couple of lines of code in the configuration language
that are loaded on demand. This is not a case where we've solved
problems that Fvwm didn't per, se, but are a case where I believe we
have solved them in a better way.

Some things we have done this way include: Maximize, FvwmAuto (not
quite a one-liner as someone posted a while back, but pretty close),
WindowList, Scroll, None, Next, Prev and many others. All of these
could be implemented in terms of other primitives once a real language
was available.

** A couple of uses of dynamic menus, suck as to display an xlock menu
that shows all the modes of the installed xlock, as determined by
querying it, and a menu that parses Red Hat's /etc/X11/wmconfig. No,
they don't fork weird, complicated processes every time they run, but
you can refresh them any time you want if you upgrade or install
anything relevant.

** Make windows start in other viewports (not just on other desktops).

** User-defined window placement (this is a recent one).

** Lots of other neat stuff. I dunno, other scwm users tend to be more
creative than me at coming up with good uses for total
configurability. There are a lot of people for whom this satisfies a
very real need to customize their environment in complex
ways. However, they are not the only ones to benefit. Look at Emacs. A
lot of people might say that the vast majority of users don't need a
programming language in their text editor. It is true that most users
don't write their own syntax hilighting, debugger interaction mode,
news reader (!), etc, but many benefit from these things existing.

* Here are some we plan to do in the future:

** We have plans to make the existing Tk and Gtk bindings for Guile
Scheme available from within scwm. This will allow built-in GUI
configuration that updates automatically. In fact, Sam Steingold has
already done some preliminary work on built-in dynamic configuration
using scwm's existing menu facilities only.

** Lower-by-one. Ever wanted to lower a window just below the next one
in the stack it overlaps, and not all the way to the bottom?
Implementing 

* I think one of the best uses is for deploying a large, site-specific
(or product-specific) configuration. This needs to adapt to individual
machine differences, allow user customization of particular parameters
dynamically, adapt to changes, and so on.

Red Hat uses FvwmM4 to get this effect. I'd guess many other sites and
individual users do as well. As people can probably guess, Greg, who
originally did the M4 stuff they use, agrees that a real language is a
much better olution to this.

* The comparison to x86 assembly is a bad example. In that case, both
the language you are compiling from, and the assembly language target,
are turing-complete. The fvwm config language is far from turing
complete. If fvwm internallly had only a bytecode interpreter and any
language facility was provided externally, I could buy this, but a
good bytecode interpreter would be harder to implement and perhaps as
costly in resource consumption as a good real interpreter.

* The sendmail config language is not, IMHO, an example of good
design.

Finally, I think people who are opposed to a real configuration
language at all are, IMO, missing the point somewhat. There are
already a number of people who want Fvwm to evolve towards having a
configuration langauge. I did not think this was true in the past, so
I thought it was inevitable and OK that Scwm should go it's separate
way. However, now that I know that at least some Fvwm developers want
to go in a similar direction, I think that vision of Fvwm's future and
my vision of Scwm are similar enough that cooperation would be a good
idea. 

It is not up to me to decide wether Fvwm will have a real
configuration language in the future. But if it does, I suggest that
cooperation is better than duplication, because the scwm team has
already done most of the hard parts. And if that happens, people who
don't want a configuration language will probably not be happy with
the future of fvwm anyway. I'd rather hear from people who _do_ want a
configuation language in fvwm, and whether they have any conccerns about wet

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

---

From: brian moore <[email-masked]>
Date: Thu, 16 Jul 1998 10:26:37 -0700

> that was better off being right in the core.

I'm not the one that started it.  Greg said that everything should be
dynamically loaded instead of #ifdef'd.  The things that are #ifdef'd
either -MUST- be #ifdef'd to allow for people to not have XPM, Shape or
other libraries or extensions or are features that cost very little.  I
see no reason why Shade (one of the features that doesn't have to be
ifdef'd as far as I can see) should be ifdef'd or even dynamically
loaded.  The cost of stripping it out, making an FvwmShade.so.1.0,
loading it and unloading it is FAR higher than the 50 lines of code that
it is.

Greg then confused this by wandering on about "small pipes" for IPC,
which means nothing to a core function.  -WHAT- IPC?

> less. At the same time, it will allow you to do a lot more.

And what indication is there that suddenly time will be spent on
reducing memory and CPU requirements of Guile?  The track record, per
your statement, is that "no major work has been done to reduce memory
consumption".  Why will that be different in the future?  All
indications of the Guile pushers are that it doesn't matter.

Saying "it is based on something that was small, but it is now really
fat" is not a good indicator of the future size.

Again, my fvwm2 is a wopping 176k.  Guile is 370k.  Even if I'm nuts and
attribute 100% of the fvwm2 code to configuration, Guile would need to
be cut in half before it would be the same size.

> philosophy, WindowShade could reasonably be broken out of the core

I dislike the handling of Maximize with WindowShade, but ripping it out
and making it a .so file would not change that.  I could compile fvwm2
as an a.out file and it still wouldn't change it.  What do file formats
and loading have to do with the logic of code?  Maybe if I don't strip
the executable it'll behave differently, eh?

> you can refresh them any time you want if you upgrade or install

I see about 80 modes in my xlock... I don't think I want a menu of all
of them.  I have a menu with a half dozen modes and 'random'.

> ** Make windows start in other viewports (not just on other desktops).

Define 'viewports'.

> in the stack it overlaps, and not all the way to the bottom?

nope, I use lower to get something out of the way that I'm not ready to
iconify yet.

> * The sendmail config language is not, IMHO, an example of good

It's excellent for what it does.  I wouldn't use it to write the tower
of hanoi, but for parsing mail addresses and rewriting them it's very
nice.  (And, no, I don't M4 my sendmail.cf's.)

It's interesting that you dislike turing complete configuration
languages in your mail daemon, but not your WM.

> my vision of Scwm are similar enough that cooperation would be a good

You haven't stated the point.

> configuation language in fvwm, and whether they have any conccerns about wet

You're using loaded terms.

FVWM does have a configuration language.  It's not turing complete, but
it is nonetheless a language.  Even twm has a configuration language.

I see no reason to make my WM turing complete.

I still find your presence here to be akin to the worms that move from
MUD to MUD saying "come to Gizmo MUD, it's better than this one!"; or
the people who wander into newsgroups to tell all the users of the
GadgetOS that GizmoOS is better and they should format and install it now.

The post from Greg (who at least has been reading this list), followed
by your "Oh, gosh, Greg, what a great idea, I agree with you fully!" chorus
backing him up looks almost exactly like the above situations.

-- 
Brian Moore                             Kill A Spammer For Jesus
Sysadmin, C/Perl Hacker, Usenet Vandal 
--
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].