Subject: FVWM: New module suggestion

From: Brady Montz <[email-masked]>
Date: 16 Aug 1996 14:16:54 -0700

I've been toying with this idea for a new module for some time, and was
wondering about other people's thoughts on it. 

Here's the background. I have two buttons on my titlebars, one of which
maximizes the window horizontally, and the other vertically. It's annoying
that if I resize first horizonally, and then vertically, I don't get what you
would naively expect, but it's understandable, since fvwm doesn't maintain a
stack of state information for windows.

I once sat down and thought about other cases where one might want state
associated with a window, but have since forgotten what I came up with. Two
things that come to my mind are stack order manipulation, and window groups.

The proposed module would keep all sorts of user definable state about
windows, and upon receiving commands (SendToModule - yippie!) could do
various things. 

Does anyone else thing that this might turn into something useful?

-- 
 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: Jason L Tibbitts III <[email-masked]>
Date: 16 Aug 1996 17:24:16 -0500

>>>>> "BM" == Brady Montz <[email-masked]> writes:

BM> The proposed module would keep all sorts of user definable state about
BM> windows, and upon receiving commands (SendToModule - yippie!) could do
BM> various things.

Hmmm.  You could achieve some of that functionality by letting functions
keep state somehow.  You'd need to allow variables and probably decision
constructs to make use of them.

Nah, too complicated.  If you want a real language, why not use a real
language?  Would Barry's FvwmPython module work for this kind of thing?
-- 
      Jason L. Tibbitts III - [email-masked] - 713/743-8684 - 221SR1
System Manager:  University of Houston High Performance Computing Center
                1994 PC800 "Kuroneko"      DoD# 1723
--
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: "Barry A. Warsaw" <[email-masked]>
Date: Fri, 16 Aug 1996 18:42:51 -0400

>>>>> "JLT" == Jason L Tibbitts <[email-masked]> writes:

    JLT> Nah, too complicated.  If you want a real language, why not
    JLT> use a real language?  Would Barry's FvwmPython module work
    JLT> for this kind of thing?

Funny, I was thinking the same thing! :-)

<http://www.python.org/~bwarsaw/pyware/>

-Barry

---

From: Brady Montz <[email-masked]>
Date: 16 Aug 1996 19:10:44 -0700

> <http://www.python.org/~bwarsaw/pyware/>

That is a good idea.

---

From: Marco Mariani <[email-masked]>
Date: Sat, 17 Aug 1996 13:34:27 -0100 (GMT-0100)

> language?  Would Barry's FvwmPython module work for this kind of thing?

I don't know Python, but would like to do some nice function.

Is there a project for FvwmPerl?

All The Best,
 Marco

---

From: [email-masked] (Dan Astoorian)
Date: Sun, 18 Aug 1996 16:53:07 -0400 (EDT)

> Is there a project for FvwmPerl?

I wrote some code for doing modules in Perl which Chuck Hines says he'll
include in the extras/ directory of the next release.

It's most useful with Perl 5 and the Tk extensions, but will still work
with Perl 4 (e.g. FvwmDebug can be written in Perl 4 with no
extensions).

The big demo is a TkPerl module which combines the functionality of
FvwmDebug and FvwmTalk (plus, unlike FvwmTalk and its cousin implemented
through FvwmForm, this one allows cut and paste to and from the command
line).

Anyone interested in a sneak preview can contact me by email; I'm eager
to get some feedback on it.

Thanks,

--                          People shouldn't think that it's better to have
Dan Astoorian               loved and lost than never loved at all.  It's
http://www.utopia.csas.com  not, it's better to have loved and won.  All
[email-masked]       the other options really suck.    --Dan Redican
--
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: "Barry A. Warsaw" <[email-masked]>
Date: Mon, 19 Aug 1996 10:43:58 -0400

>>>>> "MM" == Marco Mariani <[email-masked]> writes:

    MM> I don't know Python, but would like to do some nice function.

Python is a free, object-oriented scripting language.  Personally, I
prefer it to Tcl or Perl since it scales up much better as projects
grow.  Because of it's huge library, it's also perfect for small
scripts.  Anyway, to find out more about Python, including grabbing
everything you need to play with it and learn more, check out
<http://www.python.org/>.

-Barry

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 19 Aug 1996 11:47:27 -0400

>>>>> "Brady" == Brady Montz <[email-masked]> writes:
>>>>> "Jason" == Jason L Tibbitts <[email-masked]> writes:
>>>>> "Dan" == Dan Astoorian <[email-masked]> writes:
>>>>> "BAW" == Barry A Warsaw <[email-masked]> writes:

Brady> I've been toying with this idea for a new module for some time,
Brady> and was wondering about other people's thoughts on it.

Brady> Here's the background. I have two buttons on my titlebars, one
Brady> of which maximizes the window horizontally, and the other
Brady> vertically. It's annoying that if I resize first horizonally,
Brady> and then vertically, I don't get what you would naively expect,
Brady> but it's understandable, since fvwm doesn't maintain a stack of
Brady> state information for windows.

Resize and Maximize are particularily bad at remembering old states,
yes.

Brady> I once sat down and thought about other cases where one might
Brady> want state associated with a window, but have since forgotten
Brady> what I came up with. Two things that come to my mind are stack
Brady> order manipulation, and window groups.

Both potentially quite useful.

Brady> The proposed module would keep all sorts of user definable
Brady> state about windows, and upon receiving commands (SendToModule
Brady> - yippie!) could do various things.

Jason> Hmmm.  You could achieve some of that functionality by letting functions
Jason> keep state somehow.  You'd need to allow variables and probably decision
Jason> constructs to make use of them.

I had thought about adding this kind of stuff at some point, which I
believe is in the TO-DO list still.

Jason> Nah, too complicated.

Which is why it's still on the TO-DO list...

Jason> If you want a real language, why not use a real language?
Jason> Would Barry's FvwmPython module work for this kind of thing?

BAW> Funny, I was thinking the same thing! :-)

BAW> <http://www.python.org/~bwarsaw/pyware/>

Or Perl:

Dan> I wrote some code for doing modules in Perl which Chuck Hines
Dan> says he'll include in the extras/ directory of the next release.

And it is.

Barry - would you like me to include your FvwmPython stuff in the
extras directory as well?

Brady> Does anyone else thing that this might turn into something
Brady> useful?

I think the idea is good no matter how it's implemented.  I imagine
that using the Python or Perl interfaces would be simplest though.

Chuck

---

From: Brady Montz <[email-masked]>
Date: 19 Aug 1996 12:14:12 -0700

> <http://www.python.org/>.

Python is the much more natural choice in my opinion for this sort of thing.
I was so happy when I discovered python after struggling with perl for two
years. 

I've been reading though the FvwmPython stuff, and it seems like a good place
to start. I was thinking though that given python's capabilities, it might be
logical to turn the FvwmPython code (can't really call it a module I guess),
into a sort of Python module server, so you could have multiple python modules
runnning, with FvwmPython controlling all of them. 

Also (this might not go over too well I imagine), python's ability to be
embedded into a C program offers interesting possibilities. Last year there
was some discussion on this list about whether it would be beneficial to
replace the current message passing implementation of modules with dynamic
loading of module code into the running fvwm process. I think it's still on
the todo list as well. This might be a clean way to do that.

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Mon, 19 Aug 1996 15:50:35 -0400

>>>>> "BM" == Brady Montz <[email-masked]> writes:

    BM> I've been reading though the FvwmPython stuff, and it seems
    BM> like a good place to start. I was thinking though that given
    BM> python's capabilities, it might be logical to turn the
    BM> FvwmPython code (can't really call it a module I guess), into
    BM> a sort of Python module server, so you could have multiple
    BM> python modules runnning, with FvwmPython controlling all of
    BM> them.

    BM> Also (this might not go over too well I imagine), python's
    BM> ability to be embedded into a C program offers interesting
    BM> possibilities. Last year there was some discussion on this
    BM> list about whether it would be beneficial to replace the
    BM> current message passing implementation of modules with dynamic
    BM> loading of module code into the running fvwm process. I think
    BM> it's still on the todo list as well. This might be a clean way
    BM> to do that.

I think you've been reading my mind!  I'm glad my module [*] has
sparked these discussions because my free time is probably too limited
to explore a lot of these myself.  Hopefully my module will provide a
good jumping off point...

On your first note, I'd thought about that in some detail, but haven't
put the fingers to the keyboard yet.  I was thinking it would be
pretty cool to have a framework similar to Grail's where a naming
convention for SendToModule strings could trigger this long lived
FvwmPython module to import bits as needed, and could cache state,
etc.  But then this led me (as it led you) to thinking about embedding
the interpreter in FVWM directly, a la Lele Gaifax's PyApache for
embedding Python into the Apache HTTP server (see
<http://www.python.org/python/Contributed.html>).  The cool thing is
that this would almost instantly make FVWM ILU-aware and then you
could talk to FVWM through ILU interfaces.  There's probably a lot of
cool things you could do here if you described the interface to FVWM
via ILU.

Well, food for thought anyway.  I'm going to try to play with some of
these ideas when possible, but I encourage others to as well!  And
please, I'd love to have feedback on Fvwm.py!

-Barry

[*] is it a Python-FVWM module, an FVWM-Python module, an FVWM module
Python module, or a Python module FVWM module??? :-)
--
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: 19 Aug 1996 18:14:15 -0700

> please, I'd love to have feedback on Fvwm.py!

I too have a lack of free time at the moment. I'll have to look at the more
interesting parts of python, since until now I've mainly be using it as a
scripting language.