Subject: FVWM: Re: FVWM question

From: <[email-masked]> (Charles Hines)
Date: Thu, 14 Dec 1995 11:44:46 -0500

>>>>> "Chuck" == Chuck Thompson <[email-masked]> writes:

Chuck> Wasn't beta testing XEmacs enough for you :-)

Apparently not, eh? ;^)

I haven't been doing much of that lately, actually, which I imagine
you noticed from my lack of input to the beta list.  Work has been
pretty hectic (and my activities outside of work too) .  I apologize
for slacking off there and promise to return to beta testing ASAP...

I'm hoping to upgrade my Linux system very shortly to allow me to do
more work on fvwm and XEmacs at home.  I only have about 10Mb to do
development with on my Linux box.  Roomy enough for fvwm, but not for
XEmacs (which I obviously can't even install yet due to the space
constraints).

And since I don't have XEmacs there, I do less work on fvwm at home
than I should...

Chuck> You wouldn't happen to know of the existence of a module that
Chuck> allows for dynamic menus ala OpenWindows (i.e. every time you
Chuck> activate the menu it re-reads a configuration file to build up
Chuck> the menu)?

Nope, unfortunately.  The way the module system is set up, having
modules deal with the menus is difficult (for instance, someone else
wanted the FvwmButton module to be able to popup menus on the
ButtonPress, which doesn't work and I wasn't able to find an easy
fix).  I'd like to try and address this in the future.

Actually, you should be able to do it using a function.  Yup - I just
did the following in my .fvwm2rc:

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

AddToMenu DMenu "Dynamic Menu" Title

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

So Alt-Control Middle mouse button rereads the .fvwm2rc-dynmenu file
which was just:

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

Then I changed .fvwm2rc-dynmenu to:

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

And hit Alt-Control Middle again.  Changed Immediately.

This sounds like a good thing to add to the FAQ or to the sample rc
file.  I'll copy the FVWM mailing list on this reply too, since there
may be others out there who'd like to do this.

Hope I've been of assistance,
(the other) Chuck

ps - An unrelated subject.  Someone should put the latest precompiled
linux version of XEmacs out on sunsite so it makes it into the next
round of CDROMs that go out.  They all seem to have just lemacs-19.10.
Time to get the Linux community upgraded!

*******************************************************************************
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
*******************************************************************************
--
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: James LewisMoss <[email-masked]>
Date: Thu, 14 Dec 1995 12:34:51 -0500

>  Time to get the Linux community upgraded!

It is already there.  CHeck /pub/Linux/apps/editors/emacs/xemacs.  :)

One quick question about fvwm.  Have you ever considered embedding some
more general purpose scripting language into fvwm?  It already does a lot
of things that seem similar, and from 1.?? to 2.??? it seemed to get more
substantial (the pseudo-scripting language).

I was just playing with gwm, and it was nice being able to define arbitrary
commands, but gwm is broken in a number of ways, and the psuedo-lisp it uses
is missing quite a few things.

thanks foe the time
jim

-- 
-------------------------------------------------------------------
James LewisMoss     | University of South Carolina | Blessed Be!
    [email-masked]  |                              | Linux is cool!
-------------------------------------------------------------------
GCS/P   d-   s++:++   a24   C++++   UL++++   P+     L+++1/2  E++
        W--  N+   o?   K  w---  !O
-------------------------------------------------------------------
"Argue for your limitations and sure enough, they're yours." Bach

---

From: [email-masked] (Robert Nation 885-9815)
Date: Thu, 14 Dec 95 14:13:30 EST

>did the following in my .fvwm2rc:

With a little magic help from sed, someone could turn this into the
often requested "menu that shows all executables in a directory":

In .fvwmrc

AddToMenu DMenu "Programs" Title
Mouse 1	R   	S       DynamicMenu

AddToFunc DynamicMenu "I" DestroyMenu "DMenu"
+	"I" 	AddToMenu DMenu "Programs" Title
+ 	"I"	exec ls bin >.fvwm2rc-dynmenu; sed -f sesc .fvwm2rc-dynmenu >.fvwm2rc-dynmenu2
+	"I"	read .fvwm2rc-dynmenu2
+	"I"	Popup DMenu

and the file sesc is a sed script:

h
G
s/ */+  "/
s:\n:" exec bin/:

Cool man! But,
1. It seems pretty useless, unless you've got a bunch of programs
that are graphical and don't need any arguments.
2. I think there's a race condition between doing the exec
and the read. As I recall, "exec" always background tasks, so there's
no way to make sure its done before doing the read.

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 14 Dec 1995 14:11:29 -0500

>>>>> "James" == James LewisMoss <[email-masked]> writes:

>> Time to get the Linux community upgraded!

James> It is already there.  CHeck
James> /pub/Linux/apps/editors/emacs/xemacs.  :)

Oh good.

James> One quick question about fvwm.  Have you ever considered
James> embedding some more general purpose scripting language into
James> fvwm?  It already does a lot of things that seem similar, and
James> from 1.?? to 2.??? it seemed to get more substantial (the
James> pseudo-scripting language).

Yup.  I have considered this (for version 3 though, not version 2),
but I don't know yet.

I want to keep fvwm as small as possible while making (keeping) it
powerful.  By adding and modifying the existing rc file format, I
should be able to add a lot of functionality without bloating it, but
a somewhat standard language would be nice too.

James> I was just playing with gwm, and it was nice being able to
James> define arbitrary commands, but gwm is broken in a number of
James> ways, and the psuedo-lisp it uses is missing quite a few
James> things.

I've been meaning to look at that.  I've had the tar file sitting in
my directories for quite a while.  Just out of curiousity mostly.

I like having the emacs-lisp capabilities for XEmacs, but I think that
might be overkill for a window manager, especially with the module
interface that fvwm has.

James> thanks foe the time

No problem, but it's definitely time for me to return to my regularily
scheduled work...

Chuck

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 14 Dec 1995 14:34:44 -0500

>>>>> "Rob" == Robert Nation 885-9815 <[email-masked]> writes:

>> did the following in my .fvwm2rc:

Rob> With a little magic help from sed, someone could turn this into the
Rob> often requested "menu that shows all executables in a directory":

I remembered that request that right after I replied and had a similar
thought.

....
Rob> Cool man! But,
Rob> 1. It seems pretty useless, unless you've got a bunch of programs
Rob> that are graphical and don't need any arguments.

True.

But perhaps some more usefull ideas could be derived from this.  Use a
sed/awk/perl command to build up a menu that has function calls and
passing in the found filenames, for things like:

  - a menu of background files (and the function invokes xv on them).
  - to get all of the modes from the current version of xlock
    dynamically so you don't have to update your menu every time a new
    version comes out.
  - a list of files in a directory that you freqently edit to pop them
    up in your favorite editor (perhaps XEmacs & gnuclient to put them
    into your currently running XEmacs).

Rob> 2. I think there's a race condition between doing the exec
Rob> and the read. As I recall, "exec" always background tasks, so there's
Rob> no way to make sure its done before doing the read.

Ah.  Hadn't thought about that...

I wonder how difficult it would be to implement a solution to that.
Like an Exec variant that puts it into the background so we don't lock
up fvwm, but monitors the child to see if it's still alive and have a
Wait variant that waits for the last Exec'd child to finish.  I'll
have to look into something like that.

Chuck

---

From: [email-masked] (Todd Fries)
Date: Thu, 14 Dec 1995 15:28:02 -0600 (CST)

> substantial (the pseudo-scripting language).

So do I hear a request/volunteer to code FvwmLisp ?

-- 
Todd [email-masked]
http://www.cs.umr.edu/~tfries
--
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] (Todd Fries)
Date: Thu, 14 Dec 1995 15:56:51 -0600 (CST)

>     into your currently running XEmacs).

Hrm, cool...just don't forget that an obvious timesaver and 'intelligent'
thing to do would be to compare the timestamp of the subdir and the
timestamp of the 'dynamic menu' and only when they are different
(i.e. the subdir has new info in it) do we need to create a new
dynamic menu.  This is a subtle, but time-saving function.

---

From: [email-masked] (Dan Miner)
Date: Thu, 14 Dec 1995 22:57:52 -0700 (MST)

>     into your currently running XEmacs).

I like this idea too; it could help with a general configuration tool for
fvwm.  (Kudos to the author of the "Braindead" config program)
 
> have to look into something like that.

Does fvwm block on a fifo read?  Wouldn't writing the output to a fifo and
have fvwm read from that fifo do the trick?  You'd probably have to write
a simple little launch program to check that fvwm is currently reading
from the fifo before letting you're real "script" pump output into it.
Comments?

-- 
Dan Miner					[email-masked]
	"The longer I stare at this screen; the blanker it gets."
						Linux: try it, you'll like.
"Your program is encoded in pi."		I started with a 64
--
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].