Subject: Fvwm and Scwm

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 15 Jul 1998 14:01:25 EDT

I just checked out the fvwm mailing list archive (I was unable to
access it recently but it seems to be back now) and I saw a number of
messages about the possibility of extending fvwm with a real extension
language. Some of these posts cited scwm in several ways:

* To suggest that a future version of fvwm should use a non-Scheme
configuration language to avoid redundant development.

* To suggest that maybe scwm should eventually be renamed fvwm3, and
should actually be the future version of fvwm, this being a big win
for everyone involved.

* To mention that the last time this was discussed on fvwm-workers,
the idea of renaming scwm to fvwm3 was opposed.

I would just like to clarify some points about this. I'll be repeating
some of the things I said the last time I posted here, but I hope
people don't mind.

When I originally started the scwm project (this was quite some time
ago), I didn't even consider the possibility that it could actually be
the successor to fvwm. As I saw it, fvwm was a major project that was
in extremely wide use, with relatively closed development, and no one
would have taken me at all seriously if I suddenly posted that I had a
hack to fvwm to replace the configuration

The main reason I chose to base my work on fvwm was because, out of
existing window managers, it was the closest to what I wanted. It
already supported a great deal of configurability.

Now, the last time this possibility was raised, I said that I
personally would not be averse to scwm being fvwm3, but I was doubtful
that this was what the fvwm community really wanted, as fvwm seemed to
have a slightly different set of goals. In particular, I got the
impression that many people in the fvwm community were more interested
in low resource consumption while providing a fair amount of
configurability, than in total configurability. 

However, it seems there are now many people interested in seeing an
extension language in fvwm, possibly including the current maintainer.

As I said the last time this came up, I personally feel honored that
nayone would even think of making scwm into fvwm3. I don't know about
how the other scwm developers feel, but I spoke to Greg Badros, the
other main developer, who is also on this list, at Linux Expo, and he
agreed that a potential merge with another poject would be a good
idea.

I'm in no position to be making a decision about this on behalf of the
fvwm community, but I would like to give a few reasons why I think
guile is a good choice as an extension language. If people think these
reasons are good, then a re-merge, at least in spirit if not
necessarily literally in code, is worth considering.

* Using a made-up ad-hoc language is, I should hope, out of the
question.

* The best way to leverage existing work would probably be to use one
of the big four, Perl, Python, Tcl or Guile.

* Guile provides one of the best C APIs of any extension language. The
only extension language I've heard described as being as easy to
extend in C is Tcl. While interface to the user is important, the
interface to the programmer is important as well.

* Tcl is a bad language in many ways. Having a proper extension
language makes it natural to implement many parts of the window
manager in the language itself. Lacking true data types and any decent
support for modular code design 

* Perl has some controversial syntactic features which would make some
people hate it as much as others would hate Scheme.

* Python has nice syntax and semantics, but is not as popular as perl
or tcl.

* While Guile is currently only truly usable with Scheme, it plans to
support multiple languages in the future. Some people have attacked
this work as vaporware or as "hating other languages so much that they
will be emulated twice as slow". There is some fairness to the first
claim - the work has been on hiatus for some time. But it has recently
been dusted off, and is being worked on again. It is already possible
to use Guile with a C-like syntax, and work on other "real" extension
languages will likely proceed.

The important thing about this feature is not anything like "perl is
useless because we can just translate it into guile" or anything like
that. The important thing is that users will be given a _choice_ of
extension languages to use. I feel this is much better than any single
extension language.

An alternative approach to providing multiple extension languages is
to provide a generic interface int he core and use some kind of module
facility to connect to the individual languages.

I don't think this approach is as good. Integrating the extension
language in the core is important to properly handle the many times
the core needs to call back to user code if you want to properly
provide full programmability. Also, a good extension language provides
a number of useful data types which can be used by the core itself to
improve code organization without reinventing the wheel.

* All the hard work to make fvwm work with Guile is mostly done, in
the form of scwm. What we are doing now is cleaning things up and
adding new features. We're still working on extending the fvwm2 module
support, but it is already good enough to run the pager. A user has
recently mentioned code he has written to extend things even further
and support a number of other modules properly. We also have plans to
write an fvwmrc -> scwmrc conversion script, although this work has
understandably been delayed because scwm has been a pretty fast-moving
target.

There are some caveats however. Although scwm is already used by many
people and is fairly stable for such a relatively immature project, it
is still changing very quickly, and I wouldn't want people to rely on
it without knowing what they were getting into. I fear that a
premature change of name to "fvwm3," before the code is stable enough
to merit the name, would lead to this.

However, if people do want to work together, I think the increased
cooperation would be greatly beneficial.

 - 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: Greg Badros <[email-masked]>
Date: 15 Jul 1998 11:57:00 -0700

> cooperation would be greatly beneficial.

I agree completely.  I think our goals with SCWM, in particular with
respect to loadable extensions to manage resource consumption, coincide
to a great deal with fvwm2's future.  I hope the other fvwm-workers will
consider this before pushing forward on a separate 2.3 branch which
might unnecessarily duplicate work.

Greg

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 15 Jul 1998 15:19:20 -0400

> might unnecessarily duplicate work.

That's interesting....

Should I draw the implication from this that a 2.2-branch fvwm and scwm are
slated to merge?

I'm in favor of this, if so.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Our society won't be truly free until "None of the Above" is always an option.

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 15 Jul 1998 15:19:35 EDT

> I'm in favor of this, if so.

I don't think `slated' is the right word, since there is no officcial
agreement as yet. However, Greg and I both think a merge would be a
good idea, and meshes well with the direction in which fvwm seems to
be heading. If the major parties on the fvwm side agree, we can
discuss things further.

 - Maciej

P.S. I am not currently subscribed to this list, so please CC me for
now in any replies on this thread. I will subscribe if there appears
to be interest in further cooperation.

---

From: brian moore <[email-masked]>
Date: Wed, 15 Jul 1998 12:19:48 -0700

> I'm in favor of this, if so.

I'm not.... I don't mind greatly if the config file format changes: I
don't want my WM to have to be running an interpreter all the time.

I don't think it's a Good Thing to require a Scheme (or Perl or Tcl or
Python or Java or COBOL, for that matter) interpreter be running in
order to have static menus.

If the push is to have an interface that will -allow- Scheme, that would
be okay, but that's not what scwm is about.

If I wanted 'active desktop', I'd run Windoze.

Loadable extensions have been a part of FVWM since the days of Rob
Nation.  They were part of FVWM's future long before SCWM was even
conceived.

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

---

From: Greg Badros <[email-masked]>
Date: 15 Jul 1998 13:00:11 -0700

> Should I draw the implication from this that a 2.2-branch fvwm and scwm are

I believe fvwm 2.2 is going to be the official name of the stabilized
2.0.47x line.  2.3 will be the upcoming branch for new development (if
merging with scwm doesn't happen).

> I'm in favor of this, if so.

Merging would be good.  We'd love to hear from fvwm folks about what
sorts of things they'd like in scwm to make it more to their liking.

Greg

---

From: Andrew Veliath <[email-masked]>
Date: Wed, 15 Jul 1998 16:03:48 -0400

.........----------------==================----
..--==-  15 Jul 1998 13:00:11 -0700,
..--==-  Greg Badros (GB) mentioned:

 GB)  "Eric S. Raymond" <[email-masked]> writes:
 )) Greg Badros <[email-masked]>: > I agree completely.  I
 )) think our goals with SCWM, in particular with > respect to
 )) loadable extensions to manage resource consumption, coincide > to
 )) a great deal with fvwm2's future.  I hope the other fvwm-workers
 )) will > consider this before pushing forward on a separate 2.3
 )) branch which > might unnecessarily duplicate work.
 )) 
 )) That's interesting....
 )) 
 )) Should I draw the implication from this that a 2.2-branch fvwm and
 )) scwm are slated to merge?

 GB)  I believe fvwm 2.2 is going to be the official name of the
 GB)  stabilized 2.0.47x line.  2.3 will be the upcoming branch for
 GB)  new development (if merging with scwm doesn't happen).

 )) I'm in favor of this, if so.

 GB)  Merging would be good.  We'd love to hear from fvwm folks about
 GB)  what sorts of things they'd like in scwm to make it more to
 GB)  their liking.

..
 ~~~~~~~~~================-------------......---

I think making scwm fvwm 3.0 would be a great idea.  People who want
to use the old format can stick to the 2.2.x tree.  Also, many people
think that fvwm development has stalled (some of us consider the scwm
tree to be another fvwm2 split, which limits future development by
reducing coders).

--

        Andrew Veliath
	[email-masked], [email-masked]

---

From: Greg Badros <[email-masked]>
Date: 15 Jul 1998 13:10:09 -0700

> order to have static menus.

But if all you want is static menus, then you probably can be happy with 
many simpler wm-s than even fvwm2.  Certainly there is overhead in
running a real languge, but fvwm2 already has a lot of the overhead of a 
real language while implementing only an underpowered configuration
dialect that aspires to be a real language.

> If I wanted 'active desktop', I'd run Windoze.

Active desktop and configurable desktop are very different things.  Scwm 
is not directly hoping to be an active desktop --- the generality which
we hope it will have might enable such a thing, but isn't our purpose.

> Nation.  They were part of FVWM's future long before SCWM was even

Like what?  I must be missing something -- my fvwm2 sources have
conditional compilation code everywhere and nothing is dynamically
loadable.  Perhaps you mean modules?  It's a system that works (we've
spent some effort to make existing fvwm2 modules work with scwm as a
migration path) but isn't satisfactory in a lot of ways.

In any case, we don't claim to be inventing the idea of loadable
extensions to a wm, only hoping to implement them nicely enough the we
satisfy both the power hungry users and those wanting a more lean wm.

Greg

---

From: Greg Badros <[email-masked]>
Date: 15 Jul 1998 13:20:55 -0700

Right.  And we hope to have a one-time translator to help people move
.fvwm2rc's to .scwmrc's to aid in the conversion process.

It's a bit unfortunate (but not unreasonably inaccurate) that scwm is
considered a split from fvwm2 development -- only because the idea of
splitting is looked upon reasonably negatively.  As someone who has
contributed code to fvwm2, I understand about the problems with losing
manpower, but at the time of the "split", fvwm2 development had really
stalled.  We may have made a mistake in not searching for more support
from fvwm-workers earlier.  I say only "may have made a mistake" because 
I'm fairly certain that early periods in a projects life-cycle can
benefit from fewer designers and coders with a more unified vision and
direction.  Maciej (and to a lesser extent I) provided that vision and
direction and have a project that is very usable now, well beyond the
proof of concept stages.

I don't want to have to backpatch fvwm2 with any of the more essential
bug-fixes or features from scwm development, but have tried to be
helpful in the months after the split to the code of mine that has made
it into fvwm2 over the years.  A merge will make that job easier for
me, and will reduce duplicated efforts from groups.

Greg

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 15 Jul 1998 16:36:21 -0400

> sorts of things they'd like in scwm to make it more to their liking.

I want to say that I wholeheartedly support this plan -- and in fact,
the prospect of an fvwm/scwm makes me much more interested in working
on both.

As a user, I like fvwm2 a lot.  As a developer, I can't help but notice 
that fvwm2's configuration stuff is klugey and rigid and its internals
obscure in the extreme.

As a developer, I like the *concept* of scwm.  It's got to make a better
basis for future evolution than fvwm2.  On the other hand, I'd hate to
lose the fvwm2 look and feel, the interface-engineering tradition that
goes with it.

A window-manager that merged scwm's guts with fvwm2's glory would be ideal.

To those who object to carrying a Scheme interpreter around, I say pooh
on your prejudices.  We have only two choices here; embed a clean interpreter
or embed a lot of ad-hoc code to do logically equivalent things in a
much grubbier way.  This is not a hard decision, especially since a Scheme
interpreter can probably be made smaller than the ad-hoc code!.

What can I do to help this plan along?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
        -- George Orwell, "You and the Atom Bomb", 1945
--
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: "Eric S. Raymond" <[email-masked]>
Date: Wed, 15 Jul 1998 16:44:23 -0400

Greg Badros <[email-masked]>:
>                                 Certainly there is overhead in

Damn straight.  This is the really ugly truth about fvwm2; it's what's
kept me from being more than a passive lurker on the development list
so far.

Greg's point is valid and bears repeating until everybody gets it.  We
are *already* paying most (if not all; if not more than all) of the 
space and code-complexity overhead that embedding Scheme would cost us.
Going to an scwm-like organization would certainly give us a net decrease
in code complexity and quite possibly get us a decrease in actual footprint.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes
the law places the whole apparatus of judges, police, prisons and
gendarmes at the service of the plunderers, and treats the victim --
when he defends himself -- as a criminal.
	-- Frederic Bastiat, "The Law"
--
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 13:33:07 -0700

> the prospect of an fvwm/scwm makes me much more interested in working

Great-- I'm excited to see such strong support!

> that fvwm2's configuration stuff is klugey and rigid and its internals

Here here! :-)

> A window-manager that merged scwm's guts with fvwm2's glory would be ideal.

Let me stress that scwm is well beyond concept stages now -- your last
sentence, Eric, summarizes pretty well what scwm is!  We've got fvwm2's
glory.  With an equivalent .scwmrc, scwm feels a HELLUVA lot like using
fvwm2 to me.  The places where they differ are places where I could do
something more interesting with scwm.

> What can I do to help this plan along?

Check out our distribution available from:

http://web.mit.edu/mstachow/www/scwm.html

And start using scwm and reporting (and fixing) bugs!  We're pushing
forward on the documentation front (which is unfortunately a bit
sparse), and have a bunch of projects like the .fvwm2rc->.scwrmrc
translator, adding documentation, event-system rewrite, improved fvwm2
module support, native scheme module support, constraints-based window
positioning and sizing, loadable menu styles, loadable decoration
styles, and lots more.  After a contribution or two and an interest in
further development, we're very open about giving write access to the
CVS repository (bazaar-style! :-) ).  Maciej has done an excellent job
maintaining the distribution and using all the auto-tools to make
building scwm a virtual no-brainer (even with the complexities of using
recent guile snapshots).

Thanks for your interest... hopefully others will join in our excitement!

Greg

---

From: Greg Badros <[email-masked]>
Date: 15 Jul 1998 13:39:34 -0700

> kept me from being more than a passive lurker on the development list

We're glad to see you come out of hiding! :-)

> in code complexity and quite possibly get us a decrease in actual footprint.

Empirically speaking, it's a huge decrease in code complexity, and in
actual disk-footprint of the scwm binary (maybe now scwm binaries are
bigger, but that's due to new primitives -- they used to be smaller, and 
will be again when primitives can be dynamically loaded).  The process
image size is a little bit bigger than fvwm2, I believe, but I also push 
scwm pretty hard.  A more minimal configuration is more comparable in
running memory footprint to an equivalent fvwm2 configuration.

Greg

---

From: brian moore <[email-masked]>
Date: Wed, 15 Jul 1998 13:44:25 -0700

> dialect that aspires to be a real language.

I can't get the look and feel I want with other WM's.  I'm willing to
bet money that the vast majority of fvwm users use static menus, with
perhaps an M4-generated config based on installed software.  The menus
certainly don't change during operation.

> we hope it will have might enable such a thing, but isn't our purpose.

I fail to understand the purpose then, and how it would replace fvwm.

> migration path) but isn't satisfactory in a lot of ways.

Modules are certainly dynamically loaded and unloaded.  Converting them
to .so files would be interesting, but not necessarily useful.  (The
only real advantage would be lower IPC costs, but, then, you also lose
the simulated multithreading that multiple processes gives you.  A
bigger gain would be made by having libfvwm2 a shared object.)

I'm willing to bet that most users also leave the big-mondo-list of
config options intact except perhaps trimming out XPM's if they still
haven't gotten around to installing libXpm.  The overhead of making XPM
support a .so file would not be worth it.  Nor would 'BorderStyle' or
'Shape' or 'WindowShade' or any of the others.

You seem to be arguing that they SHOULD be .so's, since by 'Loadable
extension' you are stating that modules are not what you mean and the
only other runtime loadable extensions would be .so files.  Again, I
think that far more code would be spent on the overhead of .so's and the
hassles of REALLY ugly code.

For example, WINDOWSHADE is invoked like this a handful of times:
  if(check_allowed_function2(F_MAXIMIZE,tmp_win) == 0
#ifdef WINDOWSHADE
     || (tmp_win->buttons & WSHADE)
#endif
     )
  {

There would be no benefit to allowing the capability to come and go:
you'd lose on 50 line function and a half dozen lines throughout
borders.c, builtins.c, functions.c and resize... but to use a .so would
use more than those half dozen lines to save maybe a couple K of RAM
and hurt portability.

There is a reason such things are in the core code (they are FAR cheaper
to implement there) and there is a reason they are #ifdef'able (some
people may not have the capability to use Xpm's or Shape extensions
or just REALLY hate any change in code size and #ifdef's are free to
execute and cost virtually nothing to compile).

Again, perhaps you don't mean 'shared objects' by terms like 'loadable
extensions' and 'dynamically loadable'.  You have stated that despite
Modules being loadable and extending and being dynamically loadable that
you don't mean them.  The only thing I think you could mean would be
shared objects.

> satisfy both the power hungry users and those wanting a more lean wm.

Then what are the goals of scwm and why should it replace fvwm?  The
original post was a slightly more polite version of "Fwvm2 is dead,
quit using it or even working on future versions of Fvwm2:  work on my
code and we'll call it Fvwm3.  Be assimilated or die."

The day that fvwm requires an internal interpreted language is the day I
stop upgrading it.

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 15 Jul 1998 16:48:37 EDT

> the prospect of an fvwm/scwm makes me much more interested in working

That's good to hear.

> lose the fvwm2 look and feel, the interface-engineering tradition that

Scwm was originally derived from fvwm2 code, and thus already provides
a superset of fvwm's interface possibilities. I think the greatest
benefit would be combining fvwm's name recognition and large user base
with scwm's flexibility.

> A window-manager that merged scwm's guts with fvwm2's glory would be ideal.

I definitely agree.

> interpreter can probably be made smaller than the ad-hoc code!.

Well, libguile already provides the Scheme interpreter, so it takes
basically no space in the program itself. libguile is a bit
heavyweight right now (adds 1M or so to program RSS), but there are
plans to separate out the core Scheme interpreter from it and make
everything else into loadable modules. That should be very small
indeed. In fact, by agressive separation of fvwm code into lodable
binary modules (which libguile supports portably already), it should
eventually be possible to achieve a smaller RSS than fvwm2 itself for
some configurations.

> What can I do to help this plan along?

I think at this point your vocal support is help enough. We will have
to wait and hear from the current core fvwm developers before we can
really proceed.

 - Maciej Stachowiak

---

From: brian moore <[email-masked]>
Date: Wed, 15 Jul 1998 13:50:27 -0700

> in code complexity and quite possibly get us a decrease in actual footprint.

Changing to a new-format .rc file is hardly the same as "you need to
build a 370k language into your WM".

I have a seriously hard time believing that the config file parsing in
fvwm2 requires 370k -- yet that is the size of libguile on my system.

(And considering that fvwm2 is a whopping 176k, I doubt the overhead is
as claimed unless the rest of fvwm2 lurks in anti-memory space.)

[Please don't cc me on list mail: one copy of each item is plenty.]

---

From: Greg Badros <[email-masked]>
Date: 15 Jul 1998 14:15:43 -0700

> certainly don't change during operation.

But they should be able to change.  Why should you have to restart your
wm when you install a new application that you want accessible via a wm
"Applications" menus.

<snip>

> use more than those half dozen lines to save maybe a couple K of RAM

Tools exist to manage the complexity of dynamically loadable code in a
cross-platform way.  Once a framework is in place, having dynamically
loaded primitives is not a big problem.  It's not so much that, e.g.,
the window shading code should come and go, but more that if you don't
use window shading, you shouldn't pay for that code sitting around in
your process image anyway.  There's also an extensibility argument--
module communicate through a thin straw unsuitable for many kinds of
extensions like window decoration primitives.

> execute and cost virtually nothing to compile).

FAR cheaper?  What dynamic linking system are you using?  Dynamically
loaded code is pretty damn lightweight, and can be done cleanly and
unobtrusively to the rest of the system.

<snip>

> code and we'll call it Fvwm3.  Be assimilated or die."

:-)

> The day that fvwm requires an internal interpreted language is the day I

So perhaps scwm isn't for you, but it sounds like you're happy with
fvwm2 the way it is and that's fine.  I'm pretty sure that the generic
plans for fvwm2.3 would've left your needs behind, too, and that's fine,
too.  Along the lines of minimalistic wm with static configurations, the
horse is dead and has been beaten for quite a while now.  For those who
want or need something more, perhaps scwm is the right direction.

Greg

---

From: brian moore <[email-masked]>
Date: Wed, 15 Jul 1998 14:43:02 -0700

> wm when you install a new application that you want accessible via a wm

Then use FvwmPipe and talk to it through a pipe.  I certainly don't want
it doing something like add_menu(`find / -type f -perm 001`) every time
I pull down a menu.  Or FvwmTalk.  There are lots of ways to add menu
items without restarting Fvwm2 or even putting them in a config file.
And I sure as hell don't want application software deciding that 'make
install' means to go fuck with my window manager.  Any software that
does that will be rm'd.

> extensions like window decoration primitives.

Are you talking about modules or about core code?  Windowshade, the
example cited, is CORE code.  There isn't a huge communications overhead
in something that is in, appropriately enough, 'builtins.c'.  Your last
sentence, then is yet another red herring.  If you don't use
Windowshades, the calls will STILL have to be made to see if the bits
are set because the objecting was that they were ifdef'd.  The only
'savings' for real would be the 50 lines or so of the actual function in
builtins.c.

Is that worth it?  You seem to think so, as so far the only argument you
have presented is that unloading and loading single functions like
WindowShade should be done with .so's.  Does it really take linking with
a 370k library to unload and load a 50 line function?

> unobtrusively to the rest of the system.

Subroutine calls to fpic'd functions are cheaper than an || to a bit?
(Never mind that the subroutine call will do the exact same || to a bit
and that in the process will clean your instruction prefetch cache
and other fun.)

> > code and we'll call it Fvwm3.  Be assimilated or die."

You haven't answered the question: What are the goals of scwm and why
should it replace (not peaceful coexistence: you argued for replacement
and seem to have brought your own cheering squad along with you) Fvwm?

> want or need something more, perhaps scwm is the right direction.

If you succeed in using the Fvwm name, I will be glad to provide
facilities and time for a fork for the people who wish to continue.

Again, mail -either- the list or me.  I really don't need two copies of
every piece of mail.

---

From: Greg Badros <[email-masked]>
Date: 15 Jul 1998 15:03:20 -0700

<snip>

> 'savings' for real would be the 50 lines or so of the actual function in

Your example is bogus.  We wouldn't have a function call to do that
test, the dynamically loaded code would be just the primitives to manage 
the shading.   The window shading feature is most definitely not core
code -- if I don't use it, I don't want it loaded if it's easy to avoid
loading.  But this is way off topic, scwm's main contribution isn't
dynamically loaded code (we don't use it at all aggressively yet)--
those remarks were to pacify people concerned about code bloat of
primitives they don't care about.

<snip>

We are not arguing for replacement.  Fvwm1 and fvwm2 have their place
and will remain.  We are simply suggesting that the future direction for 
the scwm coincides with some expressed interest in future direction for
fvwm2, and that perhaps scwm is far enough along in that direction that
it makes more sense for interested developers of fvwm2 to join forces
with scwm developers.  Fvwm2 could continue to develop and have bug
fixes, but replacing its configuration language has been done, and done
well IMHO by the scwm-team many months ago.

> facilities and time for a fork for the people who wish to continue.

We have no need to use the fvwm name; scwm is a perfectly good name.  I
only wish to merge the efforts related to dynamic configurability, and
get more developers behind scwm.  Duplicated efforts serve no one well,
and I honestly believe scwm is far better positioned to be the future of 
fvwm2 users wanting more than fvwm2 is.  Those that don't need the
power/flexibility can stay behind as they did with fvwm1.  Scwm isn't
for everyone, but it probably is for those crying out for a better
language with fvwm2.

Greg

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 15 Jul 1998 18:31:51 -0400

> well IMHO by the scwm-team many months ago.

I'm building scwm now with a view to testing this assertion.  I have no
connection with Greg or Maciej, no code investment in either scwm or
fvwm2, and no axe to grind (except that I like clean design).

I'll report to the list on what I find.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Men trained in arms from their infancy, and animated by the love of liberty,
will afford neither a cheap or easy conquest.
        -- From the Declaration of the Continental Congress, July 1775.
--
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: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Thu, 16 Jul 1998 11:26:08 +0900

Late response...

mstachow> I saw a number of messages about the possibility of
mstachow> extending fvwm with a real extension language. Some of these
mstachow> posts cited scwm in several ways:

If the fvwm employs another language as the configulation language, I
think it is not fvwm. We should not forget that why fvwm throw away
the configulation language which twm uses, and employs cpp/m4 as
higher level description language. Again, we should not forget the
great design policy of fvwm.

***

mstachow> * To suggest that a future version of fvwm should use a
mstachow> non-Scheme configuration language to avoid redundant
mstachow> development.

Yes, that's right, and it should be avoided. fvwm configulation
language is just like the one of sendmail; higher (and more human
friendly) language is not provided core-part of program. fvwm
configulation description language is just like x86 assemble language; 
we can use other higher level language as we like.

mstachow> * To suggest that maybe scwm should eventually be renamed
mstachow> fvwm3, and should actually be the future version of fvwm,
mstachow> this being a big win for everyone involved.

Why? Scwm should have its own success story 'cause it is not fvwm.

mstachow> * To mention that the last time this was discussed on fvwm-workers,
mstachow> the idea of renaming scwm to fvwm3 was opposed.

Last time we do the right decision. It comes from very obvious and
very simple reason, "scwm is not fvwm."

***

Why you want to "merge" the fvwm and scwm? If scwm is great, fvwm will 
be died by itself. You don't worry about that :-)

-- -
Makoto `MAR' MATSUSHITA

---

From: Brady Montz <[email-masked]>
Date: 16 Jul 1998 09:39:49 -0700

> in code complexity and quite possibly get us a decrease in actual footprint.

I'm inclined to believe this as well.

-- 
 Brady Montz
 [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Thu, 16 Jul 1998 14:27:44 -0400

> I'm inclined to believe this as well.

I'm inclined to believe it when I see it.
So far we are being told that Scwm is at least 1 meg larger than fvwm2.

Here's whats I found on the TO-DO list that I  think is related to the
config language:

  - Access to certain window attribs from .fvwm2rc funcs, and
    simple if/else capabilities (or perhaps a module to do so)??
  - Simple static variables for .fvwm2rc functions (for toggles, etc)??
  - Add $d variable for functions to get desktop number?

Is this 1 meg of code?

I   think Greg has    said as  much.  We   need  to understand  what a
full-blown configuration language is going  to do for fvwm2 before  we
pay the price.

It seems to  me, if we are talking  about a 20% overhead increase, the
average end user should see some benefit.   Any more than that, should
come with a dramatic improvement.

Don't forget my prior point  about the conversion  script.  I have  my
doubts that  a fully  functional fvwm2 to  Scwm converter  is going to
appear.

As far as Brady's comment about the  huge segment of users watching in
quiet horror, don't forget this is the  workers list.  Most users have
no cause to be on any fvwm list, let alone the workers list.

I don't think my reaction is quiet horror, but I am concerned.  I very
much   appreciate Gregs  prior   contributions, and I  try   not to be
negative about new  ideas,  but I think  Scwm  is ahead of   its time.
Someday we may look back and wonder why we had dozens of configuration
languages, but that seems to be years off.

If   XEmacs,  Netscape and Scwm   were  using  the  same configuration
language from a  common  shared library,  that  would be a   different
story.   We just haven't arrived  in that particular  heaven yet.  Nor
does it seem to be on the horizon.

I think Scwm is a very interesting project. For  now, I am looking for
the fvwm2 project stay on track and serve its user base.

--
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: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Jul 1998 15:06:21 EDT

>   - Add $d variable for functions to get desktop number?

This is a really bad way to go. Hacking on features to the language
one at a time will result in a total mess, and will end up bloating
the code more, ultimately, then adding a real language will. The other
problem is that such simple mechanisms will severely limit what kind
of programmability a user can use in his code, because the interpreter
will be really slow unless you take great pains to design it
well. Some timing tests of SCM, the Scheme interpreter Guile is based
on, indicate that it beats the pants off _any_ other interpreted
language, and beats most byte-compilers except severely statically
typed stuff like Java. Guile has lost a bit of that speed, but Aubrey
Jaffer, the author of SCM, has offered to do a lot of speed
optimization on Guile once the basic code stabilizes enough. This is
important because it allows you to safely write code in the extension
language that does complex things, and yet still runs reasonably fast.

> Is this 1 meg of code?

I have to correct a misconception here, scwm does not have 1 meg more
of _code_, it is one meg more of _memory usage_, due to the large
amount of stuff libguile puts on the heap. And my statement about this
was acutally incorrect. I get RSS of 1.7M with a simple setup now, as
opposed to 1.1M with fvwm2 and this is still while we are in feature
explosion stage, with a _lot_ of subsequent trimming to happen later.

The scwm _code_ itself is actually smaller on disk than the current
size of the fvwm binary (and that's not even counting the fvwm modules
you can get the effect of using it, without having to run them) if you
don't count the large amounts of extra functionality (synthetic key
and mouse presses, animated moves and window shades, user-levele X
Property handling, and many others) which are orthogonal to the
configurability support itself, and which will go into dynamically
loadable shared modules pretty soon.

> come with a dramatic improvement.

Well, we're down to 60% overhead or so in some cases, and this is
again _before_ the _huge_ amounts of work that will go into reducing
the memory footprint before this is considered an end-user ready
product.

> doubts that  a fully  functional fvwm2 to  Scwm converter  is going to

I just started one today. Some parts will be tricky, but I expect to
have most of the functionality done in two days (i.e. pretty much
everything but modules).

> languages, but that seems to be years off.

I think it is fewer years off than you may think. This is an attempt
to plan for the future early.

> does it seem to be on the horizon.

Both Emacs and thus presumably XEmacs will be using Guile in the
future. So will gdb, and probably other FSF-maintained apps as
well. Netscape probably will stick with JavaScript, I'd imagine.

> the fvwm2 project stay on track and serve its user base.

I don't think anyone is even suggesting otherwise. There is no
question that Scwm is not yet fully end user ready. I think the 0.x
version number makes clear that, although it may be useful to many
people, it is primarily a developer/hacker release for people who
really like playing with their window managers. And certainly, the
concerns about the current memory usage, and the current lack of an rc
file translator, are very valid.

The question is really what should happen when the fvwm2 series
stabilizes. What comes in the next developer series? A number of
people have suggested configuration languages like python, perl or
tcl. Some have even suggested scheme, and as a result, Scwm was
mentioned. I suggest that to avoid duplicating work, if that vision is
really the future of fvwm.

 - Maciej

---

From: Greg Badros <[email-masked]>
Date: 16 Jul 1998 13:31:18 -0700

>   - Add $d variable for functions to get desktop number?

Nope-- I think you misunderstood... scwm is a bit larger in process
image size --- the code is actually smaller, I think (it certainly used
to be, and hasn't grown all that much).

<snip>

> much   appreciate Gregs  prior   contributions, and I  try   not to be

You're welcome. :-)

Greg

---

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

> to be, and hasn't grown all that much).

Last time I built scwm it was not appreciably smaller code:

-rwx------   1 bem      users      170908 May  8 19:16 scwm

And the scary one:
% ldd scwm
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6.3
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6.1
        libguile.so.2 => /usr/local/lib/libguile.so.2.0.0
        libtermcap.so.2 => /lib/libtermcap.so.2.0.8
        libdl.so.1 => /lib/libdl.so.1.7.14
        libm.so.5 => /lib/libm.so.5.0.9
        libc.so.5 => /lib/libc.so.5.4.44

Termcap??  WTF?

For comparison, 2.0.47d with a single patch for fixed-size icons that
Ian Speilman gave up getting into the tree, so which I now patch myself:

-rwxr-xr-x   1 root     system     176632 Jul 16 11:51 /usr/bin/X11/fvwm2

So the savings is about 6k.... before you start snarfing in 370k shared
libs.  (At least termcap is almost always loaded by something else.)
The scwm build was stock, both executables are stripped.

Considering you and Eric (and Brady?!) have decided that all the config
loading code was complicated bloat and that huge savings would occur by
removing it, you'd think it would show up in the size of the executable
to have so much less code.   But it doesn't.

It's the same size plus a 370k library.

---

From: Greg Badros <[email-masked]>
Date: 16 Jul 1998 14:26:25 -0700

> Last time I built scwm it was not appreciably smaller code:

Nobody said lots smaller--- it's smaller, even with a plethora of added
features through clean generalization.  Please get the chip off of your
shoulder.  You want a small wm, you have plenty of choices.  For the
fvwm2 people who want extensibility, they're gonna have to pay for it in
space somewhere... better to use an existing solution that's improving
on its own than further hack the fvwm2 configuration "language".  That's
all.

Greg

---

From: Eli Burke <[email-masked]>
Date: Thu, 16 Jul 1998 17:58:50 -0400 (EDT)

As another outsiding tossing in commentary, I just want to point out
that you are doing nothing to help your cause, which seems to be
approximately: "Don't let anyone change fvwm2 any!"

> Termcap??  WTF?
	[snip]
> libs.  (At least termcap is almost always loaded by something else.)
	[gee.. a non-arguement per your own comment]
 
> It's the same size plus a 370k library.

	What machine are you using that 370k is such an issue? An Ultrix
box? An i486 with 16M of RAM? For our edification, please tell us what
system you are running, and what it is that you want out of fvwm2/beyond. 
If you are perfectly happy with your current build, (or perhaps your build 
+ some patches that could be integrated) then lets hear it. If you will be 
unhappy if *any* more features are added, say so. 

	Once you have listed all the features that you, as the de facto
governing party, deem acceptable, explain your reasoning. If memory size
is the overriding goal, explain why, and why fvwm1/fvwm2-current aren't
good enough to stick with while we move to the next century. 

	It just sounds to me like you have configured yourself the way 
you like, and can't bear the thought of having to ever change your 
configuration. In that case, it is your perogative to stick with your
the version (which is fairly stable) and unsubscribe to this list.

	If this isn't the case, stop harping on the same subject 
(370k 370k 370k 370k!!!! Aiiigh!) and be constructive. We already know
full well that you don't want anything to do with scheme. Well, Brady
put foward several possible options; why don't you comment on those
for a change.

-- 
Eli Burke
[email-masked]
http://www.syntunix.com/~eburke/

---

From: brian moore <[email-masked]>
Date: Thu, 16 Jul 1998 15:06:32 -0700

On Thu, Jul 16, 1998 at 02:26:25PM -0700, Greg Badros wrote:
> shoulder.

Please get your preaching out of my mailbox then.  You've spent months
cleaning up the code, which, I will agree (as will no doubt anyone here)
is needed in fvwm.  To only remove 6k is not the great savings that you,
Maciej or Eric have said would happen.

Again, it is incredibly rude and arrogant for you and Maciej to show up
on this list with the attitude of zealots trying to convert the masses.
What would you think if the Windowmaker folks showed up on your lists
and started telling your users to stop working on Scwm since they were
the greatest thing since sliced bread (though far less stable)?

I wonder if Eric would like people on fetchmail-friends insisting that
mail-getter was better and that people still working on fetchmail were
wasting their time.  Perhaps fetchmail needs to have a guile interpreter
built in.

When you preach at people, expect them to be annoyed and expect them to
question your supposed facts.  That's true whether you stand on a street
corner with a Bible, or in the airport with carnations, or on a mailing
list with The Latest Gee Whiz Toy.

> running memory footprint to an equivalent fvwm2 configuration.

It's not a "huge decrease": it's 6 bloody K.  You claim this "huge
decrease" will show up in the "disk-footprint" even.  The "little bit
bigger" in RAM is at least 30%.  So 30% smaller would be a "little
smaller"?  For most of us, 30% is large, and when 6k = 3%, 6k is
small.  Consistent use of words would be helpful.

>  You want a small wm, you have plenty of choices.  For the

As I stated: if fvwm requires guile, I will, within 48 hours, have a CVS
repository, web pages, mailing lists and other toys for the people who
refuse to use your creation.

---

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

> on this list with the attitude of zealots trying to convert the masses.

Cool your jets, dude.  You're being a lot ruder right now than either 
of those two have been.  And guess which one of the three of you sounds
like a zealot?

If you keep this up, "small-is-beautiful" will lose a credible
defender, which would be a shame.  Somebody's got to keep Greg and
Maciej on their toes about the economy and footprint issues.  I was
expecting it would be you, but you're sabotaging your own arguments
rather effectively by flaming and making these peevish threats to 
start a hostile fork.

> wasting their time.  Perhaps fetchmail needs to have a guile interpreter

Fetchmail doesn't have Guile because fetchmail doesn't need Guile.  As
presently designed, fetchmail is just a keep-it-simple-stupid mail
transport agent.

If fetchmail were going to do content-based filtering or something
else that suggested it needed a Turing-complete language, I'd bolt
Guile onto fetchmail in about a nanosecond.

When you get down to it, POP and IMAP just aren't very complicated.
Because this is true, fetchmail can be both right and *simple*.  The
semantic domain of window-manager configurations, OTOH, is much, much
richer; enough so to suggest such a language.

BTW, if you'd like to join fetchmail-friends and trash my design, feel free.
I'm sure the response from the regulars there would be, hm, well,
"entertaining" is the word that occurred to me second.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

False is the idea of utility that sacrifices a thousand real advantages for
one imaginary or trifling inconvenience; that would take fire from men because
it burns, and water because one may drown in it; that has no remedy for evils
except destruction.  The laws that forbid the carrying of arms are laws of
such a nature.  They disarm only those who are neither inclined nor determined
to commit crimes.
        -- Cesare Beccaria, as quoted by Thomas Jefferson's Commonplace book
--
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 16:34:47 -0700

> of those two have been.  And guess which one of the three of you sounds

I'm not 'dude'.

> rather effectively by flaming and making these peevish threats to 

I won't have to keep them on their toes because they have yet to offer a
compelling reason to bloat the code.  It's interesting to hear someone
that has supposedly pondered the nature of open source criticizing
forks.  When program development doesn't meet the needs of a
significant number of users, it is time to fork.  I believe that
requiring guile will not meet their needs and that users will stick
with an unsupported and undeveloped product instead of "upgrading".

I believe they deserve better than that.

You think it's "peevish" to not want to follow the direction of the
current maintainer of code?  Perhaps you should add that wisdom to your
essays.  "People who don't like the way code is going dare not try to
take it in a different direction."  It will show a whole new side of
you since it contradicts much of what you have written before.

> presently designed, fetchmail is just a keep-it-simple-stupid mail

And why would FVWM benefit from Guile?  I have asked that repeatedly and
gotten silly answers.  Since you jumped right on the boat stating it
would be good, please explain what functionality would be added.

Not the general code cleanup that has been done and is sorely needed in
Fvwm, but the linking of Guile (or, for that matter, requiring any
language to be built into the core).

> Guile onto fetchmail in about a nanosecond.

Would you mandate it?  If you did, you can bet people would fork it.
("Procmail does enough, why do I need this?")

> richer; enough so to suggest such a language.

And a WM isn't that complicated.  Some very respectible WM's exist that
have no such language.  WindowMaker, AfterStep, Enlightenment -- none of
which require such a language.

> "entertaining" is the word that occurred to me second.

I didn't trash their design: I asked what functionality it would add and
was treated with 'features' like listing all the screen savers for
xlock, moving Netscape windows, and a supposedly smaller footprint. 
The first two are 'features' that are not worth the added size of the
program (and I've seen the first implemented with a shell script and
the second with FvwmScript), and the smaller footprint isn't true.

So precisely, why should I accept more complexity in the program
(certainly adding an interpreter is going to add complexity) instead of
just cleaning up the existing code?

Or is it somehow wrong to actually ask "WHY" before a feature is thrown
in now?

---

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

> you since it contradicts much of what you have written before.

Read more carefully next time.  You appear to have oversimplified my
analysis to the point of parody.

>                     Since you jumped right on the boat stating it

That's not my argument.  I think it sounds like a good idea because I
think the existing configuration language is ugly, ad-hoc, and
un-extensible.  As it is, I don't want to touch it.  But I don't have
a specific wish-list of added functions, just a design sense that the
existing language is far too impoverished to really capture the
configuration domain.

> language to be built into the core).

OK.  You concede that we need "code cleanup".  Why resist embedding
Guile as a tactic for actually accomplishing this?  There is after all
evidence (in the form of scwm itself, 6K smaller) that the tactic works.

> ("Procmail does enough, why do I need this?")

Nope.  I'd probably make Guile and filtering a build-time option.  Not
because I'd fear a fork, but simply for parsimony's sake.
 
> which require such a language.

And, IIRC, all of these are "one-true-way" WMs designed to enforce a
single theory of interface-gesture design.  Not analogous to fvwm2 at
all.

> just cleaning up the existing code?

I think your premise is wrong and Greg Badros is clearly right about
this issue, if perhaps vulnerable on others.  Embedding Guile will actually
*lower* total complexity by banishing the nasty ad-hoc code that gives
rise to so much of it.

Yesterday I believed this on general design-engineering grounds.  Today
I believe it because I've dipped into the code and configs enough to
see that it's specifically true of scwm.

You aren't going to win the total-complexity argument, because you're
simply wrong there.  You might win the big-footprint, compatibility,
or stability arguments.  I suggest you focus on those.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The direct use of physical force is so poor a solution to the problem of
limited resources that it is commonly employed only by small children and
great nations.
	-- David Friedman
--
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: 16 Jul 1998 17:56:50 -0700

> or stability arguments.  I suggest you focus on those.

We concede all of those points (and have from the beginning), knowing
full-well that things are getting better on a daily basis (except,
perhaps for the footprint, which will get lots better down the road a
bit, but is of only tangential concern while we're developing).

Greg

---

From: brian moore <[email-masked]>
Date: Thu, 16 Jul 1998 16:01:39 -0700

(tired of pasting Maciej's address by hand on my mail: if he wants to
read the list, he can subscribe: that's why God made list servers.)

> approximately: "Don't let anyone change fvwm2 any!"

No, it's Please Back Things Up With Accurate Data.

I've already stated (in <[email-masked]>):
| I'm not.... I don't mind greatly if the config file format changes: I
| don't want my WM to have to be running an interpreter all the time.
|
| I don't think it's a Good Thing to require a Scheme (or Perl or Tcl or
| Python or Java or COBOL, for that matter) interpreter be running in
| order to have static menus.
|
| If the push is to have an interface that will -allow- Scheme, that would
| be okay, but that's not what scwm is about.

I dealt with the Fvwm1.24->2.0 changes long ago.  Change isn't a big
deal.  MANDATING that an interpreter be built into the WM (or anything:
I would be pissed at the Apache Group if they made mod_perl mandatory
and I'm not thrilled that the default vim build will link perl if it
finds it without asking -- I don't use vim, though, so have only griped
about it a couple times) is uneeded.

I have asked for just why this code is needed and been given answers
like "it's not really that much code, and besides it's really SMALLER
now, not bigger!" [which is demonstrably false] or "you could do really
vital things like have a menu item with all of xlock's modes!".

Perhaps you find that a compelling argument to require an extra meg of
RAM, an alpha-level library and all else that goes with it into
something as critical as your window manager.  I don't.

> Your arguements are largely unrelated to the issues at hand, like this one:

It's unrelated that my WM will need libtermcap to run?  Why would it
need it?  Let's just link to everything, whether we need it or not, eh?

> 	[gee.. a non-arguement per your own comment]

No, it's -20 points for requiring a pointless library, reduced to -19
since at least there's reasonable odds that another application has it
in RAM already.

> unhappy if *any* more features are added, say so. 

Sun3's with 16-20M of RAM, SS2's with 64M, and a couple Pentiums with
32-64M.  scwm was noticably slower on them when I tried it in May.  (I
didn't bother trying it on the Sun3's.)

> good enough to stick with while we move to the next century. 

All I ask is that before the RAM footprint is increased by 30%-50% and
performance noticeably affected that some compelling need is shown: 
some real advantage.  Having a pulldown menu with 80 some modes of xlock
ain't it.  Nor is making Netscape's menus start in a fixed location.
Yet those are the reasons given.

> the version (which is fairly stable) and unsubscribe to this list.

Nonsense: I change my configs all the time.  I have built every release
of fvwm2 since 2.0.9, I believe, and have changed my config to deal with
the things that broke at every version.

> put foward several possible options; why don't you comment on those

I have asked for a REASON for this change.  That's hardly non
constructive.  Or is the current trend in development "let's throw all
the crap in we can because some year it may be useful"?   This is not a
minor change: for perspective, it is tripling the effective code size by
linking a library that is twice the size of fvwm2.  So far, there has
been only some pretty silly reasons for such a thing.

If we were talking "lookie, a silly feature that adds 50 lines!" and a
bunch of people thought, "it's stupid, only you will want it", it
could be ifdef'd out.  There is no choice with scwm.  You either load
an extra 370k (again, twice the size of fvwm2:  the number -is-
relevant, in that if fvwm2 were 50M we wouldn't blink at 370k) or you
don't use it.  I wouldn't object to even the stupidest features ("I want
all my menus to print upside down!") being in the distribution as long
as they were trivial to disable for people who didn't want them.  If it
were an .fvwmrc file option ('GoofyMenus On') I wouldn't care much if it
were in the default build: it's only 50 lines, after all, not twice the
size of everything else.

Brady's comments in <[email-masked]> are on the
mark for the most part.  I think his unnumbered item in the last
paragraph would actually work the best in the long run if it could be
pulled off: not so much with scwm, but with scwm, afterstep, the
abandoned/adopted fvwm95, etc.  It is an incredible waste that AfterStep
(which is actually not a bad WM, though I dislike it's configuration
methods) and others have forked off instead of working on the core and
perhaps enhancing the module API to do what they need.  If he could
bring them back into the fold and enhance the API for modules (or
perhaps as compile/link time modules like Apache modules for better
execution times, or as the same thing but dl'ing like Apache 1.3 for
flexibility) that would be a Good Thing for all the spawns of fvwm.
(Hell, FvwmWharf is stolen from AfterStep and I use it all the time.)

I said as much a couple months ago on the users fvwm list when I asked
what exactly it was missing from the module API that forbade making
'FvwmPerl', 'FvwmPython' and a non-existant Scheme module do
everything that people wanted.  See <[email-masked]>
posted on May 4th.  No direct answers as to what was missing -- just a
long "I want HTML", "I want Scheme", etc thread about what language it
should be, not why it could be less specific.  I asked how embedding
TCL would add anything in <[email-masked]> on April 29th
(no answer).

Again, I have no objection to having hooks for generic module support of
ANY language: if people want to build COBOL into their desktop, that's
fine by me.  I dislike mandating Thou Shalt Link Guile With Thine
Window Manager for such dubious benefits as xlock-menus and fixing
programs that refuse to honor geometry specifications.

---

From: brian moore <[email-masked]>
Date: Thu, 16 Jul 1998 18:50:56 -0700

> analysis to the point of parody.

Perhaps you should write more clearly then.

You argue that it is 'peevish' to hold your ground on whether or not a
feature should be installed.  I maintain that is the nature of Open
Source, whether it be Linus insisting that certain code won't make it
into the kernel or whether it is the Apache group deciding that NCSA
wouldn't do what they wanted and weren't taking patches so they'd do it
themselves.

Linus has a lot of charisma and so far has not had a serious challenge
to his decisions.  Some year, no doubt, he will, and there will be a
fork, just as the BSD's seem to fork every two years.

> existing language is far too impoverished to really capture the

Again, I said the same thing two months ago on the users list.  I really
dislike the format of .fvwm2rc (and .fvwmrc, for that matter).  Not in
that they are incapable of doing some impressive things: some of the
configs people have make it clear that with patience modules like
FvwmButtons are amazingly flexibly, including being able to fake the CDE
bar's appearance fairly well.  I dislike them because they are ugly,
rife with +'s and ""'s and other junk.

I won't, however, argue that including an interpreter (again, be it
guile, perl, tcl, python, whetever) in the core is a Good Thing.  It's
certainly a good thing as a module, and modules like FvwmCpp and FvwmM4
show that it's possible to have a module provide config files for the
parent.

It doesn't, however, belong in the core.

> evidence (in the form of scwm itself, 6K smaller) that the tactic works.

No there is no such evidence.  I could trim fvwm2 down to a 10k binary
by dynamically loading the other 160k.  Heck, my perl is only 10k by
that logic, since it uses a dynamic library.  The real footprint is
going to include libguile, as I have no other programs that I use that
require it: the disk space and RAM will not be shared by anything.

'Conceding' a code cleanup is needed is nothing new: it's been known for
years.

> because I'd fear a fork, but simply for parsimony's sake.

So why not in this case?  It's trivial to #ifdef things.  Until the
Great Style Rewrite, lots of things in fvwm2 will be ifdef'd.  That's
not what's being argued for, though.

What's being asked is not parsimony, it's assimilation.  "We want to
call scwm 'fvwm3' and will require linking an interpreter into your core
WM."

It's not "we have cleaned up the core a lot, and even fixed the weird
2-space indents in places, want to merge the cleaned up code back into
the core".  It drags along a hefty price tag in memory, execution and
disk space that you keep ignoring.

> single theory of interface-gesture design.  Not analogous to fvwm2 at

Not really, unless you restrict yourself to configuration via menus.
With AfterStep, the scattered remains of .fvwm2rc are even clearly
evident (just scattered amongst piles of directories).  It will still do
most of the fvwm2 things (of a year or so ago, anyway, before their
fork) I've tried, it's just a pain in the rear end to edit a million
files and create files with the name I want appearing in the menu.
As I said, AfterStep is still close enough to Fvwm2 that 'Wharf' works
fine and dandy and is buried the extras directory.  My main objection is
their new-improved-scatter-the-rc code.

Enlightenment is about as far from 'one-true-way' as you can get, in
fact.

> *lower* total complexity by banishing the nasty ad-hoc code that gives

I still disbelieve that: when I look at the code, I see that Greg has
done a fine job in cleaning up the patch-after-patch-after-patch that
fvwm2 is.  I don't see the gain from being the linking of Guile.
Perhaps the linking was the motivation, but that's not WHY his code is
cleaner.  If all the guile hooks were removed (or #ifdef'd), the code
would be no more messy except perhaps for the scattered ifdef's.

> see that it's specifically true of scwm.

Are you confusing the "Greg has done a massive cleanup" advantage with
linking in Guile?  The code to interpret configs is not that large a
part of fvwm (we'd have a more readable config format if it was).

> or stability arguments.  I suggest you focus on those.

All I see is that he has cleaned up the code well.  That is good: but
that doesn't answer whether embedding a language is good.  They are
seperate issues.

Again, for total complexity, you need to include libguile.  You seem to
keep forgetting that it's not a dl-stub, but a genuine library larger
than the code it is being linked to.  Does it really add no complexity
to a program to add an interpreted language?  Then, what the heck, let's
link in libperl, and tcl and python as well: why stop with one, when it
will be no more complex?

Or is your math off?

---

From: Jason L Tibbitts III <[email-masked]>
Date: 16 Jul 1998 20:41:42 -0500

>>>>> "bm" == brian moore <[email-masked]> writes:

bm> Again, it is incredibly rude and arrogant for you and Maciej to show up
bm> on this list with the attitude of zealots trying to convert the
bm> masses.

This is really ripe.  They're (in part, if not in whole) because both I and
the current maintainer of fvwm have expressed dismay at the split and much
interest in the possibility of at least working more closely.

[Two analogies.]

More than one member of this list asked them to come here.  That's why
they're here.

bm> As I stated: if fvwm requires guile, I will, within 48 hours, have a
bm> CVS repository, web pages, mailing lists and other toys for the people
bm> who refuse to use your creation.

So you're volunteering to head continuing development fvwm2 in the event
that some of the speculation about what might possibly end up being fvwm3
comes true?  I think that's a nice gesture, but we have a long way to go
before it comes to that.  After all, fvwm2 doesn't even exist in a release
form yet.  Or are you saying that you'll split development now if someone
even says that that is the plan for a far future major version increment?

 - J<

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 16 Jul 1998 22:07:39 EDT

>         libc.so.5 => /lib/libc.so.5.4.44

Termcap is needed by some versions of Guile. It's only really needed
if Guile is built to use readline, and if not, it shouldn't even get
paged in.

> It's the same size plus a 370k library.

Note that scwm has had _many_ extra primitives for quite some time
that provide extra features that fvwm does not. Before we added those,
scwm was about 2/3 the size of fvwm in compiled code.

Both these extra primitives and many of the old fvwm builtins will be
moved out of the core once we have our loadable module infrastructure
going, which should be easy - Guile provides near-transparent support
for that.

 - Maciej Stachowiak

---

From: Greg Badros <[email-masked]>
Date: 16 Jul 1998 19:12:35 -0700

> More than one member of this list asked them to come here.  That's why

Actually, I'm here because I've been involved with fvwm2 support and
development for a while. :-)

Greg

---

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

> rife with +'s and ""'s and other junk.

Fine, we agree on this much.

> It doesn't, however, belong in the core.

OK, then -- how would you feel about a design that used Guile to interpret
configs and then threw Guile away?  Would that count as being "in the core"?

> by dynamically loading the other 160k.

Wouldn't accomplish anything, as you correctly point out.  Moving a lot
of the complexity into Guile is a different case -- because the complexity
cost of Guile is somebody *else's* problem, specifically one for the clever 
specialists on the Guile team.  And one of the underappreciated benefits
of code re-use is that when lots of projects depend on a common facility
like Guile, it tends to improve much more rapidly than ad-hoc code would.

> not what's being argued for, though.

I certainly wouldn't be opposed to having "stock" fvwm2 and scwm generated
from the same source base, if that turned out to be possible and that's
what you mean.

> Enlightenment is about as far from 'one-true-way' as you can get, in

Visually, maybe.  Not logically or gesturally, which is the key point.

> that doesn't answer whether embedding a language is good.  They are

Greg doesn't think they're separate.  And since he co-implemented, and
I understand in a general software-engineering way how he might be
right, I'm inclined to believe him
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!
--
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: Bob Woodside <[email-masked]>
Date: Thu, 16 Jul 1998 22:31:03 -0400 (EDT)

> no cause to be on any fvwm list, let alone the workers list.

        But don't forget that both mailing lists are archived on the Web
site at 05:00 each morning, so anyone with a browser can follow the
discussions, subscribed or not. That's often how I catch up on the 
previous evening's goings-on, since I'm not subscribed via my account at
work. It's not quite a private club (nor should it be, IMO).

---

From: brian moore <[email-masked]>
Date: Thu, 16 Jul 1998 20:11:22 -0700

> configs and then threw Guile away?  Would that count as being "in the core"?

Would guile be mandatory, or could I preprocess them by hand (or with
another module, or cpp, m4 or even awk?).  If FvwmGuile was akin to
FvwmM4, I'd have no problem with it: it would be purely optional.
I mentiond something similar back in May.  I'd love for menus to be
written something like:

Applications {
     "The Scrape"   =>  /usr/local/bin/netscape,
     "Workman"      =>  /usr/openwin/bin/workman,
etc, with flags and icons and such shoved in in a similar style...
sorta perlish, not really, though, and as long as it wasn't laden
with "" and "+" and "I" and other magic incantations that fvwm2 has,
it would be a Good Thing.

> like Guile, it tends to improve much more rapidly than ad-hoc code would.

But that complexity adds a layer of confusion.  Try working with a
project like perl's Mail::Cclient.... are problems because of my code,
perl, the modules, or c-client (especially when the developer is working
with a -dev release of perl and I have to use a production version)? 
Or PHP's imap.so, again, using c-client.  Are problems in PHP,
imap.so, or c-client.  (Can you tell I'm playing with IMAP a lot
lately?)

Finger-pointing isn't fun.  (I'm sure Tom Dickey likes that he can
reconcile (vile|lynx)/xterm/ncurses strangeness himself, since he
controls both projects.)   Building projects around -dev code isn't fun.

-dev window managers are dangerous beasts considering the WM's role in
things.

> from the same source base, if that turned out to be possible and that's

That's exactly what I meant and what I have said for two months.  I'd
even like to see things like more stuff moved into libfvwm and libfvwm
made into a shared library, since there is a lot of duplicated code in
some of the modules (like IconMan has a pile of stuff that is in core:
those who use only core would pay a small cost to move the contents of
icons.c into libfvwm.so and the there would be a savings in IconMan to
share (both on disk and in RAM) the same library.

The current .a file only makes for 'convenience' functions without any
real benefit to the user and still there is tons of duplicated code
in the tree.

> Visually, maybe.  Not logically or gesturally, which is the key point.

It's not about piles of optional extensions, no.  But, then, neither is
a mandatory and very large extension.

> right, I'm inclined to believe him

He's right in that it was the motivator for cleaning the code.  If the
code wasn't so wierd (2-space tabs at the start of lines, 4 or 8
elsewhere, depending on mood, huge functions that extend for pages that
look awful similar to other functions, macros for skipping white space
in a config file instead of functions, etc) and he didn't want to
implement a lot of changes, he wouldn't have needed the rewrite.

The same general code cleanup is a major reason The Great Style Rewrite
hasn't happened, despite years of knowing it was needed (and tons of
features being left out for lack of bits).  If someone wrote a
way-cool-new-style-flag and was as motivated to get it in as Greg was to
get Guile in, then they would spend the time to clean up the code.

I think scwm was the kick in the pants to make him say "ugh, I need to
clean this mess up before I can do anything with it", not that by
linking in guile the code magically cleaned itself.

Were it that easy, then the Great Style Rewrite would be done and we'd
have clean code.

---

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

brian moore <[email-masked]>:
> That's exactly what I meant and what I have said for two months. 

Then why don't you solve the problem by hacking the scwm code base so
it can be built sans guile, rather than haring off in another direction
with code you admit is ugly and ad-hoc?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Rapists just *love* unarmed women.  And the politicians who disarm them.

---

From: brian moore <[email-masked]>
Date: Thu, 16 Jul 1998 20:57:02 -0700

> with code you admit is ugly and ad-hoc?

I haven't said where the first release would come from: just that it
would retain the functionality of fvwm2 without mandating Guile.  I
would even like to snarf code from AfterStep (excluding their
config-directory code): I like their pinnable menus, for example,
and the texture of their menus would make a nice option.

Afterstep is nice and compact, too.

---

From: Greg Badros <[email-masked]>
Date: 16 Jul 1998 22:40:46 -0700

> FvwmM4, I'd have no problem with it: it would be purely optional.

Not in SCWM (that's not to say that it couldn't be done that way, but
that's not how things work for us).  In particular, primitives in scwm
are more truly primitives.  Scheme code then builds on top of the
primitives useful functionality that fvwm2 had as primitives.  e.g., the 
window list code is a Scheme procedure in SCWM, but was a native C
primitive in fvwm2.  The advantage:  The end user can customize
virtually anything about the window list w/o mucking with the C code.
fvwm2 is #ifdef-fed to death.  We use very few ifdefs in SCWM, and then
only in reasonably structured ways. 

<snip>
> But that complexity adds a layer of confusion.  Try working with a

This is certainly true.  Building SCWM has an extra dependence that
fvwm2 doesn't have, but in general the stable releases build cleanly and 
are configure based (this only recently happened to fvwm2 and still
isn't mainstream I believe).

Debugging SCWM can be harder, but things will get better as Guile
becomes more stable.  Evolving with an evolving language has its
down-sides, but the guile folks are great, and development is active, so 
we know it's well worth our while.

<snip>

> linking in guile the code magically cleaned itself.

It really did work *both* ways.  The cleanup that guile gave us for free 
was more closely observed by Maciej, as he did the original embedding of 
guile.  One simple example of how guile simplified a *lot* of code was
in the arguments to the primitives.  fvwm2 primitives each parse their
own arguments, sometimes using one of a bunch of somewhat standard
functions, sometimes in completely ad-hoc ways.  This makes the
configuration language far less uniform and understandable.  All of the
ugliness is take care of for us in SCWM, and our primitives are shorter
and more readable.

Greg

---

From: Tomas Ogren <[email-masked]>
Date: Tue, 21 Jul 1998 19:44:49 +0200

On 15 July, 1998 - Andrew Veliath sent me these 1.7K bytes:

> to use the old format can stick to the 2.2.x tree.                            

And the confusion... fvwm 2.* could be newer than 3.* ... hm.. no
thanks..

I'm against a merge.. I tried scwm a month ago or so.. (0.7 I think),
but it was far too slow for me.. (usually on pretty slow sun-machines,
50/50 running remote as well)

Also, I really don't like guile/scheme/lisp... Lemme quote tcsh:
"Too many ('s." 8)

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student of Computer Engineering at the University of Umeå
`- Sysadmin at ing.umu.se
--
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].