Two comments:
1. I don't want fvwm to go down the road of some other projects where various
people slap an interpreter for every language known to man in it (vim comes
to mind). If we want to put an extension language in it, I think we should
pick one and stick with it. I believe that multiple languages usually need
be supported only because people are too lazy to learn a new language, or a
mistake was made when choosing the first language supported.
2. I personally think tcl is a poor choice for such a job. Like perl, it never
seemed (to me) properly suitable for large scale projects (although it's
not nearly as write-only as perl is), and I'm sick of how every time a new
tcl/tk release comes out I have to want 6 months for people to "port" their
tcl apps to the new version (tkdesk for example). That just doesn't seem
right. Languages I think would work would be scheme, python, or java. They
all are multithreaded and I know that python and scheme work nicely
embedded in C programs. I assume java does too. I would prefer scheme or
python myself.
I think a cool way to do it would be to run the interpreter as a module,
requiring a much richer fvwm/module interface probably, and then have it
manage the the various modules people have written in that language. So it
would be completely feasable to support multiple language environments
simultaneously, as well as C modules which use this richer interface to do
cool things like draw menus and 3d titlebars and stuff.
--
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 Wed Apr 29 1998 - 12:51:03 BST