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

From: <tma_at_nettest.dk>
Date: Fri, 1 May 1998 10:33:38 +0100

Kendrick Vargas <kvarga01_at_fiu.edu> writes:

> On Fri, 1 May 1998 tma_at_nettest.dk wrote:
>
> > Brady Montz <bradym_at_cs.arizona.edu> writes:
> >
> > > "Vlad D. Markov" <markov_at_monmouth.com> 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

--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri May 01 1998 - 03:48:24 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:38:01 BST