tma_at_nettest.dk writes:
> Brady Montz <bradym_at_cs.arizona.edu> writes:
>
> > I suspect there is wide agreement with these two points:
> >
> > 1. Fvwm's internal configuration language could be changed for
> > the better.
> > 2. If we add a new language, it should be done as a module. Most likely
> > people would want this module to be as tightly coupled to fvwm as
> > possible for speed, using whichever dlopen, mmap, and threading
> > facilities available on the various architectures.
If it would lead to a cleaner interface, I would have no objection to
making the interpreter part of the fvwm core.
> Here we disagree. I would prefer to abandon the current configuration
> language as a basis for the future development, adopt an existing
> configuration language, and then add fvwm functionality/API to this
> new language.
Exactly. The current configuration language is a hodge-podge of
compromises and kludges. Fvwm still is the leading, most configurable
WM around and I don't want to take away from the considerable
achievement fvwm still represents.
However, I very strongly feel that any new and significant development
should not be compromised by a misplaced desire to retain compatibility
with existing config files. We probably should look at easing the
transition by providing a conversion tool, and that would not require
a compromise.
> I we for some reason want to be backward compatible, we will
> automatically limit ourselves to a small number of languages, but we
> will keep the current user group happy.
Anybody wishing to stay with the current fvwm2 can do so anyway.
Fvwm2 is a mature, powerful product and will still be relevant for
quite a few years even if new development ceases.
> I would much prefer to use an existing configuration language if at
> all possible. Inventing a new language usually means the product will
> be delayed quite a bit longer than necessary. And why not take that
> complication out of the project?
Absolutely. There are too many configuration languages as it stands.
Creating a new one would be madness.
So, maybe we should re-focus on which language would be most suitable.
Scheme is already being implemented in the fvwm-derived ``scwm''.
Since we don't want to re-invent any wheels, anybody wanting scheme
should look at contributing to scwm.
Questions:
1. What would we want to do with the configuration language?
2. How often would we use it.
3. What kind of language would people find most approachable?
(Especially if it's used only occasionally?)
Comments? Other questions to ask?
Cheers
--
Manfred Bartz <mbartz_at_werple.net.au>
--------------------------------------------------------
"No! Try not. Do, or do not. There is no try." -- Yoda
--
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 Mon May 04 1998 - 06:09:19 BST