Subject: FVWM: Command to send arbitrary stuff to modules

From: Brady Montz <[email-masked]>
Date: Sun, 24 Mar 1996 11:23:28 -0700 (MST)

Modules can send arbitrary command to fvwm. I think that it would be
nice if fvwm could send commands to modules. Perhaps something like:

Send "FvwmModule" "command string"

which would send the string "command string" to all instances of FvwmModule
which are currently running. And then fvwm could send a packet to the
appropriate module which contained the text. 

This idea came up when somebody suggested that it would be cool if FvwmIconMan
could use the arrow keys to move from one window to another, and of course,
the other window list/icon box modules could do exactly the same.

A more ambitions way to use this would be to write a module which could extend
the fvwm command language. For example, something I've often thought would
be cool, but couldn't think of an easy way to do, is if fvwm could maintain
state for windows that the user could modify. I currently have two buttons
on my title bars, one which calls "Maximize 0 100" and another which does
"Maximize 100 0". If I click on the horizontal zoom button, then the vertical
zoom button, I would expect the window to first expand horizontally, and then
expand vertically so that it occupies the entire screen. Instead, when I click
on the vertical button, it just goes back to its original size. The problem
obviously is that fvwm doesn't maintain a stack for the various window sizes.
Also, it might be cool to be able to write fvwm functions which could remember
where windows are, or their window stack position, etc. Not easy things to add
to fvwm without bloating it, but if you could send commands to modules, you
could write a module whose only purpose is to implement extensions to the fvwm
command language.

Any thoughts? 

[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: "David A. Berson" <[email-masked]>
Date: Sun, 24 Mar 1996 12:26:01 -0500 (EST)

> Any thoughts? 

I second this idea.  I too recently have wished that a couple of windows
could remember some state information and have title buttons

If someone implements this, they should be sure to support inter-module
communication.  I.e., allow module1 to send a string to fvwm like
   "send module2Name command"

An interesting use of such a feature is to use it to support modules that
can reconfigure themselves on the fly.  Say, have FvwmTalk support
   "send moduleName configCommand"
Sure would beat edit .fvwmrc/restart cycles.

David.

---

From: "Brandon M. Browning" <[email-masked]>
Date: Sun, 24 Mar 1996 14:31:47 -0800 (PST)

> Sure would beat edit .fvwmrc/restart cycles.

Sorry to jump in, but I second this wholeheartedly.  While I love FVWM
more than any other WM, something that I really hate is the fact that when
I make a change to my .fvwm2rc file, I have to restart.  While I'm at my
console, this isn't a problem ... but when I'm sitting up in the computer
lab it's a pain (it takes FOREVER to restart).  Jarl's Buttons have the
option of an external rc file which I really, *REALLY* like.  I can make
changes w/o starting FVWM.  Not to compare apples to oranges, but OLWM
lets me change menu items w/o restarting.

I'd love to see an option that I could add to a menu:

+      "Reread Config"  Reconfig

-- Brandon Browning                                                          )
   Powertie Software                                                        (
   http://www.powertie.org/                                                c[]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Someone will try to honk your nose today.

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 25 Mar 1996 14:50:04 -0500

>>>>> "Brandon" == Brandon M Browning <[email-masked]> writes:

Brandon> Not to compare apples to oranges, but OLWM lets me change
Brandon> menu items w/o restarting.

Actually, you can pretty much do this right now (although it may not
be an entirely elegant solution).

To add to an existing menu on the fly, you can just call AddToMenu.
To recreate it you can call DestroyMenu, and then AddToMenu.

So, if you rewrote your .fvwm2rc file correctly (or safer, had a
separate file just for menu definitions), you could just reread it.

In fact, check out this.  In your ~/.fvwm2rc file you could have:

----------------------------------------------------------------------
Mouse 2 R MC DynamicMenu

AddToMenu DMenu "Dynamic Menu" Title

AddToFunc DynamicMenu "I" DestroyMenu "DMenu"
+ "I" Read .fvwm2rc-dynmenu
+ "I" Popup DMenu
----------------------------------------------------------------------

And ~/.fvwm2rc-dynmenu could look like this:

----------------------------------------------------------------------
AddToMenu DMenu "Dynamic Menu" Title
+ "Rlogin" Module FvwmForm Rlogin
+ "QuitVerify" Module FvwmForm QuitVerify
----------------------------------------------------------------------

This binds Alt-Ctrl-MiddleMouse to this dynamic menu function.
Editing the file .fvwm2rc-dynmenu would result in an immediate change
when you pop up the menu next time with no fvwm commands needed on
your part.

Granted, if you haven't changed that file, it still does waste the
time of reading the file before popping up the menu, but with a not so
large menu this won't be too bad.  But if you used it to get the menu
to where you liked it and then just bound the resulting menu directly
instead of through this function, it wouldn't matter anyways.

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

IBM Internal email:                        "Go back to sleep, Chuck.  You're
  [email-masked],              just havin' a nightmare--of course,
  HINESC at FISHKILL, HINESC at FSHVMFK1    we are still in Hell." Gary Larson
*******************************************************************************
--
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]> (Charles Hines)
Date: Mon, 25 Mar 1996 15:11:24 -0500

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

BM> Modules can send arbitrary command to fvwm. I think that it would be
BM> nice if fvwm could send commands to modules. Perhaps something like:

BM> Send "FvwmModule" "command string"

BM> which would send the string "command string" to all instances of
BM> FvwmModule which are currently running. And then fvwm could send a
BM> packet to the appropriate module which contained the text.
....
BM> Any thoughts?

I've been thinking about ways to add to & improve the module
interface, and this seems like it might be a good addition.  I've
added this idea to the TO-DO list.

I thought it would be useful to be able to send messages to a running
module to implement things like new & different menu styles in a
module (for those people who wanted different menu styles, like say
Pie menus) without bloating fvwm.  And as you (and others) started
pointing out, there could be other potential uses.

Chuck

---

From: [email-masked]
Date: Mon, 25 Mar 96 21:37:35 +0000

>To recreate it you can call DestroyMenu, and then AddToMenu.

	I'm new to the list but I do have a comment to make along
these lines...

	I have organised (well almost) my ~/.fvwm2rc so that it is a
minimal file, which reads a set of files from ~/.fvwm which define
functions, styles, keymaps, menus, modules and buttons (for
FvwmButtons module definitions, since I have a number of them!).  I
had intended to make use of the read command to enable me to implement
a 'reconfig' command, which would allow me to change configuration but
not have to do a restart, which takes ages, since all the modules have
to be restarted, and very likely only one has been modified.

	However I ran into a problem... While I could start a Menu
afresh (i.e. implemented a function NewMenu which destroys the old
instance first) there was now way to implement a NewFunc, which
resulted in all my functions being doubled up...

	So why isn't there a corresponding DestroyFunc command? And
infact it would make sense (or it seems so to me) that this should
exist and it maintains the orthogonality of the command syntax?
Things that are created can be destroyed.  On a similar note,
orthogonality would suggest that perhaps KillModule should be
DestroyModule?

	So again why is there no way to destroy an existing function
definition?

	I also second the suggestion of an FVWMHOME environment
variable.

	Fergal.

-- 
Fergal Mc Carthy, Digital, Ballybrit, Galway.   [email-masked]
Technical Computing Group System Administrator. Ph: +353-91-754149
http://tc-www.ilo.dec.com/~fergal               DTN:      822-4149

  "a key to the understanding of all religion is that a god's
   idea of amusement is Snakes and Ladders with greased rungs."
                                - Terry Pratchett, Wyrd Sisters

---

From: Chris Taylor <[email-masked]>
Date: Mon, 25 Mar 1996 16:54:25 -0500 (EST)

> So why isn't there a corresponding DestroyFunc command?

The DestroyMenu directive destroys both menus and functions. The syntax is the
same. It isn't documented in the fvwm man page.

I agree about creating a DestroyFunc directive, even if it's just an alias of
some sort for DestroyMenu.

Chris Taylor     / My views do not represent \ PGP public key available
[email-masked] \    those of Cabletron.    / via keyserver or request

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 25 Mar 1996 16:56:43 -0500

>>>>> "fergal" == fergal  <[email-masked]> writes:

....
fergal>         However I ran into a problem... While I could start a Menu
fergal> afresh (i.e. implemented a function NewMenu which destroys the old
fergal> instance first) there was now way to implement a NewFunc, which
fergal> resulted in all my functions being doubled up...

fergal>         So why isn't there a corresponding DestroyFunc command? And
fergal> infact it would make sense (or it seems so to me) that this should
fergal> exist and it maintains the orthogonality of the command syntax?
....
fergal>         So again why is there no way to destroy an existing function
fergal> definition?

Actually I was wondering the same thing when I posted my suggestion
earlier...  I believe there should be and I'll see about getting one
in there for the next release.

Actually, the Menu and Function code are done via nearly the exact
same code, so the DestroyMenu will work to kill a function too.  I
just tested this to be sure.  I'll add DestroyFunc as an alias
essentially for it in the next release.  In the meantime DestroyMenu
should work for you.  If anyone finds problems with this, let me know.

fergal>         I also second the suggestion of an FVWMHOME environment
fergal> variable.

I think I may end up putting this in there...

Chuck

---

From: Dave Goldberg <[email-masked]>
Date: Mon, 25 Mar 1996 16:58:06 -0500

>>>>> [email-masked] writes:

> resulted in all my functions being doubled up...

I think I recall someone once posting that DestroyMenu was supposed to
work on Functions too.  Then again I don't bother destroying anything
so it's not an issue for me :-)

> 	So why isn't there a corresponding DestroyFunc command?

If I'm correct in my guess above then DestroyMenu should be aliased to
DestroyFunc.

> And infact it would make sense (or it seems so to me) that this
> should exist and it maintains the orthogonality of the command
> syntax?  Things that are created can be destroyed.  On a similar

Agreed.

> note, orthogonality would suggest that perhaps KillModule should be
> DestroyModule?

I disagree.  Running a module involves starting a separate process.
On most, if not all, of the platforms that fvwm runs, the removal of
that process is referred to as killing.  Killmodule fits.  Menus and
functions are objects native to the fvwm process.  Destroy fits there.

Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: [email-masked]

---

From: Jarl Totland <[email-masked]>
Date: Mon, 25 Mar 1996 23:08:05 +0000 (WET)

> functions are objects native to the fvwm process.  Destroy fits there.

But maybe there should be a DestroyModule function to destroy the definitions
for a module - so you don't end up with doubled FvwmForms and FvwmButtons?

Haven't experimented much with rereading yet, so maybe this is no problem?

Vyrdsamt,
-Jarl

---

From: Dave Goldberg <[email-masked]>
Date: Mon, 25 Mar 1996 17:45:22 -0500

> But maybe there should be a DestroyModule function to destroy the
> definitions for a module - so you don't end up with doubled
> FvwmForms and FvwmButtons?

If that's what he meant, then I retract my statement.  However, I was
under the impression he simply meant renaming KillModule.  Even if we
do get a DestroyModule that removes module definitions, we'd still
need KillModule around for stopping Module processes.

Dave Goldberg

---

From: [email-masked]
Date: Tue, 26 Mar 96 08:51:52 +0000

On Mon Mar 25, 96, at 17:45:22, Dave Goldberg wrote :

JT> But maybe there should be a DestroyModule function to destroy the
JT> definitions for a module - so you don't end up with doubled
JT> FvwmForms and FvwmButtons?

DG> If that's what he meant, then I retract my statement.  However, I was
DG> under the impression he simply meant renaming KillModule.  Even if we
DG> do get a DestroyModule that removes module definitions, we'd still
DG> need KillModule around for stopping Module processes.

	I agree... My meaning was ambiguous.  As Jarl suggests I was
interested in destroying the Module definition, but was (stupidly)
considering including this to be associated with KillModule, which in
hindsight is NOT a good idea!

	So yes I do want a way to destry the definition of a Module,
to more easily facilitate dynamic reconfiguration without restarts

	Fergal.