Subject: FVWM: Proposal on modules/languages

From: Brady Montz <[email-masked]>
Date: 01 May 1998 10:37:26 -0700

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
 [email-masked]
--
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: Tue, 5 May 1998 8:50:14 +0100

"Patrick K." <[email-masked]> writes:

> Sometime in the late 1900s it was said:
> 
> > I agree with #3, but I'm not ready to say that Perl, Python, Scheme, or
> > Tcl is the language.  I don't see any of them as being 'configuration'
> > languages.  Sucking in menus by doing:
> > 
> > %RootMenu = (
> >     'Title'  => 'Toys',
> >     'Xterms' => (
> >                'regularterm' => 'xterm',
> > 
> > (etc) would be sort of nifty, but does that really belong in a WM?  (And
> > I'm beginning to think it's nifty enough that I should play with
> > FvwmPipe or X11::Fvwm and see if I can hack something like that....)
> 
> 
>    Now I don't want to yelled at :)   but how about taking
>    the approach of HTML tags?  What you typed up there got
>    me thinking, what if we could have tags for each menu and
>    menu items?  Like:
> 
>    <MENU NAME="Root-Menu">
>       <MENUITEM   NAME="Xterm"
>                   ACTION="xterm -T $LOGNAME@$HOSTNAME">
> 
>       <SUBMENU    NAME="Utils">
>          <MENUITEM   NAME="Top" ACTION="rxvt -T Top -n Top -e top">
>          <MENUITEM   NAME="Xload" ACTION="xload -fg green -bg black -hl
red">
>          <MENUITEM   NAME="Calculator" ACTION="xcalc">
>       </SUBMENU>
>       <!--
>        ! and so on ... -->
>    </MENU>
> 
>    Same with FvwmButtons... you could use the syntax used for
>    HTML tables (ie. <TABLE> tag).
> 
>    Or does this sound totally stupid? :)

I, for one, would say that we would just replace one obscure
configuration language with another obscure configuration language.

How would you create the above on the fly from information found in
the file system?

/tonny