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

From: [email-masked]
Date: Thu, 30 Apr 1998 13:28:14 +0100

Michael Hucka <[email-masked]> writes:

> I haven't had time to look at it, but I thought tkgoodstuff did something
> like this for fvwm2.

tkgoodstuff is a module... I want to change the basic configuration
language of fvwm...

/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 [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Thu, 30 Apr 1998 13:28:24 +0100

Manfred Bartz <[email-masked]> writes:

> [email-masked] writes:
> 
> > Has anybody been thinking about introducing something like TCL in
> > fvwm. To me it looks like most current fvwm commands can be translated
> > directly to TCL commands. This would automatically add
> 
> <stuff deleted> 
> 
> > What do you think? Will it work? Anybody out there want to help?
> 
> I don't want to discourage you and I don't want to start a flame war
> either.  
> 
> However, my experience has been that tcl/tk is excellent for small
> appletts but not for medium or large applications.  All the larger
> tcl/tk based apps that I know of (tkdesk, tkinfo, and a few I can't
> remember now) are too buggy to rely on.  That is surely due to the
> absence of data-types and type checking in the language.

I don't want to write major pieces of TCL here. I just want a better
fvwm configuration language with all the modern programming constructs
(if, while, for, procedures, etc) and some easier concepts for the
more obscure features of the current configuration languages,
especially the functions (this is not a flame on the origial
developer, as I believe the idear is alright for small functions, but
very difficult for larger functions.).

Also I miss maving acces to the current state of fvwm from the
configuration file itself. That would be easy to add within a TCL
framework.

And yes I do know that many believe the TCL programming paradigm to be
ugly, but given the goal of being backward compatible with the current
configuration files, I see no other usable languages. Of cause we
could invent one ourselves, but that is exactly what I want to
prevent...

> 
> There is a fvwm derived project (scwm) that uses scheme (lisp?) as a
> scripting language.

Maybe I should look into that...

> 
> My suggestion would be to look at ``slang'', which I believe is some
> sort of C-interpreter.  I don't know how good it is, but it is used in
> the ``jed'' editor for example. 

These are undoubtably better languages than TCL, at least from a
"pure" language design point-of-view, but, then the current
configuration files will not be compatible with the new ones.

Maybe it is just me that want the configuration files to be backward
compatible... If that is not an issue, then I would use perl. My main
reasons for this is the large base of modules for perl and especially
perl/tk that would enable lots of new possiblities... An perl is
multi-threaded!!!

> 
> Regards
> -- 
> Manfred Bartz <[email-masked]>
> ---------------------------------------------------------------------
> Politics is the art of looking for trouble, finding it, misdiagnosing
> it and then misapplying the wrong remedies.           -- Groucho Marx
> --

---

From: [email-masked]
Date: Thu, 30 Apr 1998 14:21:15 +0100

Bruce Stephens <[email-masked]> writes:

> [email-masked] writes:
> 
> > I want to use TCL as the configuration language of fvwm instead of
> > the current command set. The reason for using TCL and not perl,
> > slang or any other configuration language, was to make the new
> > TCL-based configuration files completely backward compatible with
> > the current configuration files.
> 
> Ah.  Clever.  Just looking at my .fvwm2rc suggests it's not entirely
> Tcl-friendly, but it's very close.  Specifically, the function
> definitions have + as the first word, so you'd need to keep track of
> what the last definition was or something.  And the module definition
> lines are weird: you'd presumably have to use something nasty like
> redefining unknown.

True!

Of cause, we would want to add a new more TCL friendly module
definition, which shouldn't be too hard... When everybody has
converted to the new configuration language (2-3 years), the
compability stuff can be removed...

/tonny