Subject: Re: FVWM: Re: FvwmEvent 1.0 (FvwmAudio++) Alpha release

From: [email-masked]
Date: Fri, 1 May 1998 00:49:31 -0400 (EDT)

Too late.

%%%%%%%%%%%%%%% jim knoble %%%%%%%% [email-masked] %%%%%%%%%%%%%%%%%

On Thu, 30 Apr 1998, Vlad D. Markov wrote:

: I appreciate Fvwm's small memory consumption and speed. My computer is
: an old 486 DX66. I prefer not to bring up an interpreter to do common
: tasks. I hope Fvwm does not get bloated.

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Fri, 1 May 1998 10:33:38 +0100

Kendrick Vargas <[email-masked]> writes:

> On Fri, 1 May 1998 [email-masked] wrote:
> 
> > Brady Montz <[email-masked]> writes:
> > 
> > > "Vlad D. Markov" <[email-masked]> writes:
> > > 
> > > > I appreciate Fvwm's small memory consumption and speed. My computer is
> > > > an old 486 DX66. I prefer not to bring up an interpreter to do common
> > > > tasks. I hope Fvwm does not get bloated.
> > > 
> > > I agree. That's why I made the point (and will make again) that we
should
> > have
> > > at most one interpreter running. I negelected to say that fvwm should
work
> > > perfectly nicely without having an interpreter built in as well. That's
> also
> > a
> > > prerequisite I would want satisfied.
> > 
> > And I agree too, even though I have plenty of memory.
> > 
> > One could argue that fvwm already have an interpreter built-in! This
> > interpreter takes up some 200 lines of code. A TCL interpreter takes
> > up 4000 lines (I believe) and can usually be loaded as a shared
> > library. And if you use anything like tkman, tkgoodstuff or similar,
> > you already have that shared library loaded...
> 
> Can I ask WHAT'S THE BIG DEAL?!?!?

One might ask, why not include the interpreter directly in the core?
It can actually reduce the fvwm module protocol somewhat!!! With a
full programming language in the core, we can send small pieces of
code to be evaluated by the core. Right now we have to communicate a
lot with the core to do anything sensible.

> The way I see it, the fvwmrc file simply sets a bunch of variables, and
> maybe does interpretting for some complex functions, but even then it's
> minimal.

The problem, as I see it, that fvwmrc *NOT* just "sets a bunch of
variables", but include lots of other information, like the functions,
menus and module configuration.

> Otherwise, to get interactive, you use a MODULE... like FvwmTalk,
> or FvwmCommand, or whatnot.

But, I don't want to get interactive. I just want an easier to use
configuration language with more expresive power.

> As far as I can tell, there's an M4 processor,
> as well as a C-preprocessor type module, or something like that. If you
> want this extra configurability, why not just create a module like
> everything else and as the first line of your fvwmrc, immediately use the
> module.
> 
> The beauty of FVWM is in the modules. Use them.
> 			-peace

I *COULD* add a new module as outlined by you and others, but I expect
that I would have to extent the fvwm module protocol masively to
accomodate all the query functions. And I would still have the timing
holes that are present in the fvwm module protocol (IFAIK).

/tonny

---

From: Chris Siebenmann <[email-masked]>
Date: Fri, 1 May 1998 17:19:41 -0400

I admit that I don't see any particular need to make the entire
configuration file built around (or parsed through) a language if one
just wants to improve some bits of it (say, the ability to have more
sophisticated functions). I semi-agree that the easiest way to get
more sophisticated functions may be to find a small (and hopefully
elegant) extension language to stick into fvwm2.

 The fvwm2 configuration language is already very optimized for what it
does (which is the natural state of configuration languages). I can't
but think that any replacement that was trying to be a general purpose
language would be worse.

	- cks