OK, these are good points (I'm leaving the followup gunk at the bottom of my
post for those who don't have threading mailreaders).
I see three main choices:
1. Keep the current architecture.
2. Add an SOL (some other language) to FIL (fvwm's internal language).
3. Replace FIL with SOL.
I personally would prefer #3. (thanks to Manfred and tonny for pointing out
the costs of my attempt at compromise). But my desire for compromise remains,
since there are many people who use fvwm that don't need a fat interpreter in
the executable. As for #2, I don't like that at all due to the need to
partition functionality between FIL and SOL(s).
The logical reply to that is to use swig, so people can use whichever
interpreter they wish. It probably is a simple matter to implement FIL (or
something like it), as a swigable thing for those who prefer the status quo.
I immediately see two hurdles:
1. Currently modules tell fvwm what to do by sending FIL strings to fvwm. This
won't work anymore, since the module writer can't know beforehand which
language fvwm is going to be using. The solution to this is to probably
give the modules the swig interface to fvwm as well.
2. Once we have an interpreter running inside of fvwm, it will probably have
it's own share of state. It's likely modules will want to
read/write/execute those (note that this is the modules talking to the
interpreter, not fvwm as in #1). I don't see any way to prevent modules
from developing dependencies on the SOL here, but as long as we have a good
enough mechanism to support #1, modules should only talk to the SOL when
then absolutely have to, so that's OK.
Then there is the problem that I currently have plenty of people sending me
bug reports which include there .fvwm2rc files. It's hard enough getting these
.fvwm2rc's to work right now. I'll probably go mad if people start sending me
.fvwm2rc's which require me to install tcl version x.y to fix their bug.
So, if we support:
a. FIL only, we frustrate people who want to do things in a real language (if
only I could write a function to do ...)
b. 1 SOL, then we better make sure we don't pick something which many people
hate.
c. 2 or more SOL's, then I don't see any way to avoid doing lots of work and
dealing with logistical headaches.
So, proposing that we choose #b, replacing FIL with one SOL, we're looking at
Manfred's questions:
Manfred Bartz <MBartz_at_promail.com> writes:
> 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?
I see two other questions:
4. How many resources are we willing to use, both in code bloat and requiring
people to install whichever files language X needs to operate.
5. How nicely does language X lend itself to embedding.
My answers:
1. I want to be able to set the usual fvwm options (a=b type statements),
maintain state about windows (so I can write functions to do things like
SmartPlacement), and have real functions. I'd like to have it support a
module interface, and multiple namespaces (ala python) so that I can
write modules in that language which won't have namespace collisions with
each other. Multithreading is probably a reasonably requirement.
2. I would probably do a LOT of programming in such a language, some of it
released as modules.
3. guile or python
4. Either guile or python could be made to work with a minimal installation of
stuff, but the simplest thing for people to do is install the whole damn
thing. Probably true for any interpreted language.
5. Both guile and python were designed from the beginning to be embedded. It's
probably fairly easy to map the window manager data structures onto python
objects and vice versa. Guile might be more of a stretch.
Some URLs of potential interest:
http://www.python.org
http://www.red-bean.com/guile/
http://www.sun.com/sunworldonline/swol-10-1997/swol-10-scripting.html
http://www.lib.uchicago.edu/keith/crisis/
--
Brady Montz
bradym_at_cs.arizona.edu
--
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 - 14:51:35 BST