This discussion on extension languages is quickly going to descend into
chaos. I see the following desires:
1. A better internal language. I feel that the configuration language used by
fvwm is both (a) starting to creak and (b) a good basis for something
better. I imagine that some who want to put a language like tcl into fvwm
are doing so to enable doing some cool configuration stuff, like generating
menus or determining which colors to use, or writing real functions (not
just event handlers) which can do cool things like loop over the window
list and move windows around, etc.
2. The ability to use features inherent in a given language to make deep
changes to the behavior of fvwm. Perhaps using java to make a portable
graphical system, or python to be able to write embedded/tightly integrated
modules.
3. The ability to write more sophisticated modules in general.
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.
So, my proposal:
Lets table the discussion on tcl/perl/python/java/icon/scheme/... and focus on
improving the internal language and the module interface(s). Both are
necessary before we dive into grafting on an interpreter, and it's quite
possible that if done right, they will obviate the desire for such a grafting.
(I argue that if we add an interpreter, we will have to change the internal
language for two reasons: it's likely we will want to refer to services
provided by modules written in language X in the .fvwm2rc, and we might wish
to unload some of the bloat in the internal language to language X.)
--
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 Fri May 01 1998 - 12:37:52 BST