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

From: [email-masked]
Date: Wed, 29 Apr 1998 12:37:48 +0100

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

- all the usual programming constructs like if, while, for and procedures

- data structures, though only the ones supported by TCL, i.e. lists

- if we add TCL/tk too, we would be able to do all sorts of things
currently done through some of the modules, like FvwmForm and the
newly announced FvwmEvent.

Some of the concepts of fvwm configuration files can be generalized to
the corresponding concepts of TCL or TCL/tk, e.g. functions, colors,
menus...

And some of the fancy configuration options such as M4, can be done
away with, so we will have much more adaptive configurations.

I can put some work into this, though not enough for a complete
rework...

What do you think? Will it work? Anybody out there want to help?

/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: Bruce Stephens <[email-masked]>
Date: 29 Apr 1998 13:01:07 +0100

[email-masked] writes:

> fvwm. To me it looks like most current fvwm commands can be
> translated directly to TCL commands.

Yes.  It's been done for scheme, at least:
<URL:http://web.mit.edu/mstachow/www/scwm.html>.
--
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: Manfred Bartz <[email-masked]>
Date: 29 Apr 1998 23:16:18 +1000

> 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.

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

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. 

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
--
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: Bruce Stephens <[email-masked]>
Date: 29 Apr 1998 14:32:53 +0100

[paragraphs moved to beginning for readers uninterested in Tcl]

In any case, my major concern with Tcl as a window manager (and
especially if it tries to do module things in the same process) is
that it's not multithreaded yet.  I *really* don't want my window
manager to hang if its built in pager (or something) goes into a loop.

I don't think it's a silly idea, necessarily, but it requires some
thought as to what the goals are.  And looking closely at scwm surely
makes sense.

[Tcl bit]

Manfred Bartz <[email-masked]> writes:

> remember now) are too buggy to rely on.

exmh is one of the best mail readers out there.  Personally, I use
Gnus, but exmh is solid.  There's also a Tcl web server (tclhttpd),
which seems pretty robust.  And tkman is a superb manpage reader:
anybody that still uses xman definitely ought to try it.  (None of
these are trivial applications, either.)  

Closer to home, <URL:http://www.isode.com> uses Tcl based management
tools for its directory and messaging products, and our LDAP/WWW
gateway is basically Tcl.  We find it relatively robust.

> That is surely due to the absence of data-types and type checking in
> the language.

Possibly, or perhaps it's just that the applications are trying to do
ambitious things and haven't had enough maintenance effort yet.
--
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: Brady Montz <[email-masked]>
Date: 29 Apr 1998 10:50:39 -0700

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
 [email-masked]

---

From: Michael Hucka <[email-masked]>
Date: Wed, 29 Apr 1998 15:43:08 -0400 (EDT)

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

I think the web page is:
    http://www-personal.umich.edu/~markcrim/tkgoodstuff/index-orig.html

-- 
Mike Hucka   --   [email-masked]   --   PhD student, UNIX admin & programmer
  Do you like Microsoft or use Microsoft products?  Then I think you should
  read these articles and think about whether Microsoft deserves your support:
  http://www.netaction.org/msoft/
  http://www.latimes.com/HOME/NEWS/BUSINESS/UPDATES/lat_microsoft0410.htm
--
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: brian moore <[email-masked]>
Date: Wed, 29 Apr 1998 13:06:55 -0700

> directly to TCL commands. This would automatically add

How would that be different from X11::Fvwm for Perl and the fvwmpython and
fvwmperl modules in 'extras' with 2.0.46?  Same basic thing?

-- 
Brian Moore                             Kill A Spammer For Jesus
Sysadmin, C/Perl Hacker, Usenet Vandal 
--
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: Bruce Stephens <[email-masked]>
Date: 30 Apr 1998 09:58:15 +0100

Brady Montz <[email-masked]> writes:

> 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.

Yes, that seems a good way to do it.

Another idea would be a more radical look at what window managers do.
i.e., write an extension to Tcl to allow Tcl programs to do the things
that window managers need to do.  So it would allow me to catch events
when windows were about to appear (to let me reparent them), to
reparent them (which Tk can already do), to warp the cursor, and so
on.  I'd guess that would allow some things to be done in independent
processes, which might be fun.  This is not particularly related to
fvwm, however.
--
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: Chris Siebenmann <[email-masked]>
Date: Thu, 30 Apr 1998 19:40:45 -0400

| 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

 Heavily programmable window managers have been done before, without
huge amounts of success. If one wants to try again, I strongly suggest
using a language that's as good and as clean as possible (not TCL;
perhaps Python).

 In the context of fvwm, I suggest using the language as an extension
mechanism instead of the core of the window manager. Look at things that
just can't be done in fvwm right now and see if you can make it possible
to program them in the extension language. I doubt that many people want
to complicate their configuration files by having to write them in a
language.

 I would also suggest that one start by writing a module wrapper such
that one can write fvwm modules in the language. That would be a useful
way to add various pieces of functionality and to let you experiment
with what sorts of language bindings were needed to allow for useful
features. Bonus points for making the result use as little memory
as possible, given that one selling point of fvwm over other window
managers is memory usage.

	- cks

---

From: "Vlad D. Markov" <[email-masked]>
Date: Thu, 30 Apr 1998 20:48:04 -0400

I appreciate Fvwm's small memory consumption and speed. My computer is
an old 486 DX66. I prefer not to bring up an interpreter to do common
tasks. I hope Fvwm does not get bloated.
--
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: Brady Montz <[email-masked]>
Date: 30 Apr 1998 20:09:16 -0700

> tasks. I hope Fvwm does not get bloated.

I agree. That's why I made the point (and will make again) that we should have 
at most one interpreter running. I negelected to say that fvwm should work
perfectly nicely without having an interpreter built in as well. That's also a 
prerequisite I would want satisfied.

-- 
 Brady Montz
 [email-masked]