Subject: FvwmAnimate custom dialogue?

From: [email-masked] (Paul D. Smith)
Date: 03 Nov 1998 14:03:38 -0500

So, I started up the FvwmAnimate module (based on the latest stuff in
CVS as of this morning or so) and it's pretty neat.

If I select options from the menu lists, they all (seem to) work.

But, if I select the "Custom Settings" option and get the FvwmForm
dialogue (way cool feature reuse there! :), nothing ever seems to take
effect regardless of what button I push.

I tried modifying the Effect, then using either or both of Apply or
Apply&Save, but nothing changes.  If I reopen the dialogue, it's all
back as it was.

PS. I wonder if anyone's considered the ability to have "checkbox
    menus", where one or more items on the menu can be "selected"?  You
    could probably fake it with mini-pixmaps or something, but you'd
    have to Destroy/recreate the whole popup each time.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Tue, 03 Nov 1998 14:21:34 -0500

> CVS as of this morning or so) and it's pretty neat.

Thanks.

> Apply&Save, but nothing changes.  If I reopen the dialogue, it's all

Obviously it worked/works for me.

As you may see, on apply, FvwmForm is supposed to generate a series of
"*FvwmAnimate" commands.   Try recompiling FvwmAnimate with  debug on.
You should see the commands coming into FvwmAnimate.

>     have to Destroy/recreate the whole popup each time.

More features in FvwmForm would be nice.

If you've ever tried to use it for help, you will see it falls short.
All the text lines look like they are double spaced.

I'd also like to be able to change fonts and colors as I go.

I once   started  this, switched  to   FvwmHtml, and then   decided to
re-think what I really wanted.

> --
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 03 Nov 1998 15:37:08 -0500

%% Dan Espen <[email-masked]> writes:

  de> As you may see, on apply, FvwmForm is supposed to generate a series of
  de> "*FvwmAnimate" commands.   Try recompiling FvwmAnimate with  debug on.
  de> You should see the commands coming into FvwmAnimate.

OK, I'll check it out.

  >> have to Destroy/recreate the whole popup each time.

  de> More features in FvwmForm would be nice.

Actually, I meant fvwm's builtin menus, not FvwmForm stuff: I was
thinking of the menus FvwmAnimate creates to select different speeds,
modes, etc. and how you can't tell what the _current_ setting is from
those menus.

  de> If you've ever tried to use it for help, you will see it falls short.
  de> All the text lines look like they are double spaced.

  de> I'd also like to be able to change fonts and colors as I go.

Indeed.

A year or so ago I posted a whole laundry list of things I wish FvwmForm
did.  Tops on my list are cutting and pasting in the text fields (!!!),
a few extra command language operators, and maybe some simple keybindings.

No one seems to be working on FvwmForm.  Someone encouraged me to try
FvwmScript which seems a _lot_ more advanced, with almost a whole
language there.  I never tried it because it didn't compile on SunOS
(see my reports on this over the last two days), and obviously you can't
use it for configuring FvwmAnimate unless it moved out of the extras/
directory into the mainstream.

Ultimately, I guess, I'd prefer to see a forms module that was based on
a more standard scripting language, rather than a whole new one.  Maybe
Guile/Tk or something.  Obviously the problem here is that it kind of
sucks that standard modules need other packages like Guile/Tk to work.

  de> I once   started  this, switched  to   FvwmHtml, and then   decided to
  de> re-think what I really wanted.

What's FvwmHtml?

---

From: Dan Espen <[email-masked]>
Date: Tue, 03 Nov 1998 16:16:06 -0500

> modes, etc. and how you can't tell what the _current_ setting is from

Oh sorry, no wonder I couldn't  completely parse what you were saying.
I certainly could  tear down and  re-create the menus after a  setting
change.  It did occur to  me that after I  did the "Custom" thing, the
menus were somewhat redundant...

> What's FvwmHtml?

Sorry,  I'm not being  very clear.  I started  to write  a module that
would accept commands like:

*FvwmHtml<H1><font color="pink">Cool Idea of the Week</font></H1>
*FvwmHtml<P>
*FvwmHtml<A href="Module XXX">Click Here<a>

Anyone else is welcome to the idea.

---

From: [email-masked] (Paul D. Smith)
Date: 03 Nov 1998 16:57:08 -0500

%% Regarding Re: FvwmAnimate custom dialogue?; I wrote:

  de> As you may see, on apply, FvwmForm is supposed to generate a
  de> series of "*FvwmAnimate" commands.  Try recompiling FvwmAnimate
  de> with debug on.  You should see the commands coming into
  de> FvwmAnimate.

  pds> OK, I'll check it out.

Hmm.  Very weird behavior now.

First, FvwmAnimate seems to be exiting with "Dead Pipe" quite often when
I start up the configure menu.  But not every time :-/.  I didn't notice
this happening before I enabled debugging (to enable, I did this:

  cd modules/FvwmAnimate
  rm *.o
  make CFLAGS='-g -DDEBUG'

).  Here's a sample output:

    ...
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateTwist $(Twists)
  Sending unlock
  Header[2] is 22, read 16
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateWidth $(Linewidth)
  Sending unlock
  Header[2] is 22, read 16
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateDelay $(Delays)
  Sending unlock
  Header[2] is 45, read 16
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateEffect $(RANDOM?Random)$(FLIP?Flip)$(FRAME?Frame)$(FRAME3D?Frame3d)$(LINES?Lines)$(TURN?Turn)$(TWIST?Twist)
  Sending unlock
  Dead Pipe

But of course fvwm2 is still running; I can even start another instance
of FvwmAnimate and it works fine for a while.  It doesn't always happen
in the same place in the menu definition, either; here's another one:

  Got command: *FormFvwmAnimateCommand      *FvwmAnimateWidth $(Linewidth)
  Sending unlock
  Header[2] is 22, read 16
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateDelay $(Delays)
  Sending unlock
  Header[2] is 45, read 16
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateEffect $(RANDOM?Random)$(FLIP?Flip)$(FRAME?Frame)$(FRAME3D?Frame3d)$(LINES?Lines)$(TURN?Turn)$(TWIST?Twist)
  Sending unlock
  Header[2] is 19, read 16
  Got command: *FormFvwmAnimateCommand      *FvwmAnimateSave
  Sending unlock
  Header[2] is 21, read 16
  Got command: *FormFvwmAnimateButton       restart   "F3 - Reset" F3
  Sending unlock
  Header[2] is 20, read 16
  Got command: *FormFvwmAnimateButton       quit "F4 - Cancel" F4
  Sending unlock
  Header[2] is 14, read 16
  Got command: *FormFvwmAnimateCommand Nop
  Sending unlock
  Dead Pipe

Very odd.

Second, continuing on the track of the original bug :), when it doesn't
exit I see that FvwmAnimate only receives the first couple of commands
that it should.  After I press the Apply button, I see these lines:

  Header[2] is 14, read 16
  Got command: *FvwmAnimateIterations 12
  Found line for me: *FvwmAnimateIterations 12
  Sending unlock
  Header[2] is 14, read 16
  Got command: *FvwmAnimateTwist 0.500000
  Found line for me: *FvwmAnimateTwist 0.500000
  Sending unlock

... and that's it!  Sure enough, if I change the Iterations or Twist
values, they _do_ get applied, but all other values don't.

I'm thinking there's some kind of memory thing or _something_ going on
here.

---

From: Dan Espen <[email-masked]>
Date: Tue, 03 Nov 1998 22:36:44 -0500

> this happening before I enabled debugging (to enable, I did this:

Seems like a good way to turn on DEBUG.

>   Got command: *FormFvwmAnimateCommand      *FvwmAnimateEffect $(RANDOM?Rando
> m)$(FLIP?Flip)$(FRAME?Frame)$(FRAME3D?Frame3d)$(LINES?Lines)$(TURN?Turn)$(TWI
> ST?Twist)

This command bothers me a  little, all my commands are  built in a 200
byte work area.  It's  not 200 bytes long, but  its a little closer to
200 bytes than I wanted to get.  I don't think this has anything to do
with the problem.

>   Dead Pipe

Here it is  seeing commands that  it knows are not  for  itself, so it
just skips  them.   The Dead  Pipe is  normally  a reaction  to  fvwm2
closing the pipe.

>   Found line for me: *FvwmAnimateTwist 0.500000

The next thing it should be  getting is a *FvwmAnimateWidth command, I
don't see anything special about that command.  It seems like fvwm2 is
eating the rest of the command.  Or, could there be some limit to what
can be on the pipe at one time?

> I'm thinking there's some kind of memory thing or _something_ going on

You're right, there is something going on, but I'm  afraid we are both
clueless. I'm at a special  disadvantage, because  I can't create  the
problem.

Well, wait a minute, I got an idea about the Dead  Pipe, tried to test
it,  and  now   I  think  I'm  a little   more  confused.    I changed
modules/Module.c so that  when  it calls DeadPipe, it  passes  "errno"
instead of just a  "1".  I changed  FvwmAnimate so that when it prints
its dead pipe message, it prints the passed arg.  It then proceeded to
spontaneously die in  different places with a  DeadPipe, and errno 13,
(EACCES  -  Permission  denied).  I've   had  it  die during the  form
definition, during an apply, and I also saw it  just stop like you did
above.

I also  saw it dump out huge  quantities of FvwmForm  definitions over
and over  even  though    each form  definition  is preceeded    by  a
"destroymoduleconfig".

I think there is something wrong with the module pipes, but don't know
much about them.  Guess I have to start reading.

---

From: [email-masked] (Paul D. Smith)
Date: 04 Nov 1998 02:22:33 -0500

Hmm.  I compiled a debugging version on Linux and I can't reproduce the
FvwmAnimate problem there; it all seems to work OK.  I don't get the
Dead Pipe messages, either, although I didn't try your change of passing
errno to DeadPipe().

This is looking stranger and stranger... I think I'll whip out my trusty
Purify tomorrow and see if anything pops out at me using that on fvwm2
and FvwmAnimate.  I think I have an Xnest server around, too, so it
shouldn't be too painful to debug :)

BTW, another thing I noticed was that with DEBUG on, many modules print
various information.  However, most of the time it's impossible to be
sure who's printing what.

IMO this is another _prime_ candidate for a generic set of routines in
libfvwm: debugging functions.  I suggest something like:

  * A global variable char *ModuleName that every module must define; it
    should use the optional name if one was given.

  * A function dbprintf() or similar that takes a printf()-style format
    string and arguments.

  * A #define that hides the dbprintf() and maps it to empty if DEBUG is
    not set.

Here's a sample--Note!  I wrote this from scratch right here, it's not
even been compiled!  Also, if someone really wants to do this there's
some hackery in autoconf that needs to be done to deal with the
stddarg.h vs. varargs.h issue.  I can provide sample code since I did
this for GNU make already:

 $ cat debug.c

 #include <stdio.h>
 #include <stddarg.h>

 #include "debug.h"

 extern char *ModuleName;

 struct __db_info _db_info;

 void
 dbprintf(const char *fmt, ...)
 {
   va_list ap;

   fprintf(stderr, "[%s] %s:%d: ", ModuleName, _db_info.file, _db_info.line);

   va_start(ap, fmt);
   vfprintf(stderr, fmt, ap);
   va_end(ap);

   fputc('\n', stderr); /* So callers don't have to do it. */
   fflush(stderr):      /* This should be unnecessary. */
 }

 $ cat debug.h

 #ifdef DEBUG
 # define DB(_x)    do{_db_info.file=__FILE__;_db_info.line=__LINE__; \
                       dbprintf _x;}while(0)
 #else
 # define DB(_x)
 #endif

 struct __db_info { const char *file; unsigned long line; };

 extern struct __db_info _db_info;

Then you invoke it like:

  DB(("Found a foobar: %d", foobar_count));

This provides a common look-and-feel to all debugging output, and it
automatically includes the module name and filename & linenumber from
which the debugging statement was printed.  It also (as written)
automatically adds a newline so developers don't need to.

Just a thought.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 04 Nov 1998 10:20:57 +0000

> CVS as of this morning or so) and it's pretty neat.

It is very neat. But does anyone feel a bit uncomfortable that this
module is making up its own menus and forms?  Maybe uncomfortable is too
strong a word and I don't mean to criticize Dan for his efforts.  It's
just that there are lots of modules that could benefit from this kind of
interaction and I'm wondering if it wouldn't be better to have all the
simple modules configurable from a form or menu.  (besides I don't like
the colours of the FormFvwmAnimate 8-).

Would it be easy to take the menu and form building out of FvwmAnimate? 
Would it make FvwmAnimate any simpler? Would it be easy to duplicate
this stuff for the other modules?

Here's a quick first guess at what could be simply configured:
fvwm2 (OK not the key, buttons, styles, decors, menus or functions)
FvwmAnimate      FvwmAudio        FvwmAuto         FvwmBanner       
FvwmCascade      FvwmCommand      FvwmConsole      FvwmCpp          
FvwmDebug        FvwmEvent        FvwmIdent        FvwmM4           
FvwmPager        FvwmPipe         FvwmSave         FvwmSaveDesk     
FvwmTile         FvwmWinList      FvwmScroll       FvwmTalk 

Things that don't have a static limit for config options
fvwm2
FvwmBacker       FvwmButtons      FvwmForm         FvwmGoodStuff    
FvwmIconBox      FvwmIconMan      FvwmScript       FvwmTaskBar
FvwmWharf

Any thoughts?
Cheers,
Tim.

PS what happened to FvwmConfig?

---

From: Dan Espen <[email-masked]>
Date: Wed, 04 Nov 1998 08:17:35 -0500

>     should use the optional name if one was given.

A trick I picked up from FvwmEvent? is to include a leading "*" at the
front of  the internal module name.  This   becomes useful for parsing
config  strings,    and  generating commands.    Debugging  and  error
messaging would then be done with ModuleName+1.

> automatically adds a newline so developers don't need to.

And a good one.

---

From: Dan Espen <[email-masked]>
Date: Wed, 04 Nov 1998 09:00:21 -0500

Tim Phipps <[email-masked]> writes:
> module is making up its own menus and forms?

Well, I didn't.  Actually, I'm trying to set conventions for the names
used also, so I won't get conflicts with user created menus and forms.

 "FormFvwmAnimate", "MenuFvwmAnimate", "MenuDelayFvwmAnimate".

> Maybe  uncomfortable is  too   strong a word and   I  don't  mean to
> criticize Dan for  his efforts.  It's  just that  there  are lots of
> modules  that could benefit  from  this kind of  interaction and I'm
> wondering  if it wouldn't  be better to  have all the simple modules
> configurable from a form or menu.

It is my expressed intention  to make that happen.   Are you trying to
say that there  should be one  configuration  dialog for the  whole of
fvwm?

If thats where you are going I disagree.  However,  in my master plan,
the whole configuration dialog would "appear" to be one thing.

One of the reasons that configuration dialog  has to be in FvwmAnimate
is that   the  dialogs are   dynamic based on   the  current  state of
FvwmAnimate.   For example,  if  you stop  FvwmAnimate, the only thing
left in MenuFvwmAnimate is "Start FvwmAnimate".

> (besides I don't like the colours of the FormFvwmAnimate 8-).

There is no current way  to globally configure  FvwmForm.  But I guess
that  wouldn't be too  hard.  We could make  that the default FvwmForm
dialog.  I    would entertain suggestions   on  different defaults for
FvwmAnimate in the time being.

> Would it be easy to take the menu and form building out of FvwmAnimate? 

No.  The form and  menu building is  based on the  current FvwmAnimate
configuration and state.

> Would it make FvwmAnimate any simpler?

Have you looked at the code?
I think its pretty simple as is.

> Would it be easy to duplicate this stuff for the other modules?
> 

As you point out, some of the modules are very adaptable to this.
For others, maybe not.

In the case of FvwmForm, there is  a case for a builtin configuration.
We just discussed default   colors and fonts.   How about  a  tutorial
also.  I think the tutorial idea applies to all the "hard" modules.

There  are  also  parts  of fvwm2   that   would be well   adapted  to
configuration dialogs.  For example, "theme choosing", "menu style".

> Any thoughts?

All good issues, glad you brought them up.

> PS what happened to FvwmConfig?

Still in the extras directory with this note:

Use of this module is discouraged, since the options it allows are far
less in variety than fvwm itself can allow.

Note,  that that is not  true  for FvwmAnimate.  Every  aspect of  its
behavior is configurable.

There is another tool, I think its  the "DotFile Configurator?"  which
does a    pretty  sophisticated job  of configuration.    However, its
monolithic.  I am trying  to show that each  module should provide its
own configuration tool when possible.

---

From: Dan Espen <[email-masked]>
Date: Thu, 05 Nov 1998 11:17:55 -0500

> much about them.  Guess I have to start reading.

After I updated my home config last night with the latest changes,
I can no longer reproduce any problem with the "Custom" dialog.

Unless I hear otherwise, I have to consider the problem fixed.

> > -- 
> >  Paul D. Smith <[email-masked]>         Network Management Developm

---

From: Tim Phipps <[email-masked]>
Date: Fri, 06 Nov 1998 17:39:20 +0000

> say that there  should be one  configuration  dialog for the  whole of

No, my screen isn't big enough.  What I meant was that having some
modules configurable by menus and others not might make the fvwm package
look a bit fragmented.  If we could get a lot of the modules to go the
way of FvwmAnimate it would be a big improvement.

> the whole configuration dialog would "appear" to be one thing.

This would be nice.  How about fvwm generating some menus every time the
ModulePath changes? e.g. MenuStartModule, MenuStopModule,
MenuConfigModule
that would have an entry for every module it found. Start and stop would
just start and stop them but MenuConfigModule would run an FvwmForm with
whatever form the module had created.  Maybe MenuConfigModule could be
auto created so that only real-time configurable modules were on the
menu by looking for *FvwmFormModuleSomething configuration lines.  I'd
like the auto menus to include a mini-pixmap if there were one on the
pixmap path and to have a hot key assigned. (if you solve this one it
might be worth putting auto hot key generation in all the menus or
having auto hot key generation being a menustyle)

> FvwmAnimate in the time being.
Whatever defaults you pick will not suit everyone.  I like dark
backgrounds and light text but then I don't sit near a window.  Some
sort of global setting would be nice but maybe FvwmForm is not the way
to go.  I haven't tried FvwmScript but it does appear to be a bit more
flexible.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 30 Nov 1998 18:15:06 +0000

What seems a long time ago Dan Espen wrote:
> 
> However,  in my master plan,
> that  wouldn't be too  hard.

If we have the modules saving and restoring config files do you think it
makes sense to have a ~/.fvwm2 directory? ~/.fvwm2rc could go in there
as ~/.fvwm2/fvwm2rc and the module conf as e.g. ~/.fvwm2/FvwmAnimate. We
could alter the Send_ConfigInfo message to use ~/.fvwm2/<Module name>
and create a Save_ConfigInfo message.

Modules like FvwmForm could ask for two sets, one for the default and
one for instance specific stuff.

I don't know how pre-processing might fit into this, I'd like to be a
able to have the module config files #include another to set default
colours but I can see it being a bit difficult to save such a set up.

For autoconfiguring I'd like some opinions on the following:
*) At startup fvwm automatically runs the (new) module FvwmAutoConfig.
*) FvwmAutoConfig scans the ModulePath and creates some menus depending
on what it finds:
	*) A run menu with the modules it finds (with mini-icon guestimates)
	*) A stop menu ''
	*) A config menu that calls FvwmForm as Form<Module-name>
*) These three menus placed on the default menu
*) when modules start they create Form<Module-name>
----
Alternative
*) At startup fvwm runs FvwmAutoConfig which does the following
*) creates a ModuleMenu with a submenu (Menu<Module-name>) per modules
*) puts ModuleMenu on the default system menu
*) creates an initial Menu<Module-name> that has Run and Run+args
entries
*) when modules run they manage the Menu<module-name> menu

Am I barking mad?
Tim Phipps.

---

From: Dan Espen <[email-masked]>
Date: Mon, 30 Nov 1998 13:55:47 -0500

> and create a Save_ConfigInfo message.

Auto-sensing and saving into a $HOME/.fvwm2 directory is a good idea I
keep  putting off since  we only have  .fvwm2rc and .FvwmAnimate right
now.

> one for instance specific stuff.

As you  may remember, I've been working  on FvwmForm for a  while now.
Right now, it  auto-creates the form  "FormFvwmForm".   This form lets
you set default  fonts and colors for any  other FvwmForm that doesn't
do overrides.  If I get to it,  it might also create FormFvwmFormHelp.
An actual form painter is only a concept at this point.

As it stands   right now, no matter   what name its  invoked under, it
always reads .FvwmForm looking for defaults.  Then it reads ".<Alias>"
allowing it to be configured from a file rather than from .fvwm2rc.

I'm thinking that I might be able  to autoconfigure an "rlogin" dialog
or a "print screen" dialog, but actual "do anything" autoconfiguration
seems like it's a way off.

> colours but I can see it being a bit difficult to save such a set up.

Right now, I don't think pre-processing  fits in at  all.  At least it
doesn't   seem to be   applicable  to the  2  modules   I've tried  to
autoconfigure.

> *) when modules run they manage the Menu<module-name> menu

This is consistent with where I think we have to go.  Right now,
fvwm2 has a tiny little built-in menu bound to button 1 that allows you
to exit.  All the builtins are hard coded in fvwm.c:

void SetRCDefaults()
{
  /* set up default colors, fonts, etc */
  char *defaults[] = {
    "HilightColor black grey",
    "XORValue 0",
    "SetMenuStyle default black grey slategrey white fixed fvwm"
    "TitleStyle Centered -- Raised",
    "IconFont fixed",
    "WindowFont fixed",
    "Style \"*\" Color lightgrey/dimgrey, Title",
    "Style \"*\" RandomPlacement, SmartPlacement",
    "AddToMenu builtin_menu \"Builtin Menu\" Title",
    "+ \"Exit FVWM\" Quit",
    "Mouse 1 R N Popup builtin_menu",
    "AddToFunc WindowListFunc \"I\" WindowId $0 Iconify -1",
    "+ \"I\" WindowId $0 Focus",
    "+ \"I\" WindowId $0 Raise",
    "+ \"I\" WindowId $0 WarpToWindow 5p 5p",
    NULL
  };

I see all of this coming out of an autoloaded module instead.  I would
expect that  building a module menu  has to be  more than just sensing
that the  module is there, so add  it to a menu.   I think each module
presents its own unique requirements.

> Am I barking mad?

Without update access, yes.

---

From: Michael C Tilstra <[email-masked]>
Date: Mon, 30 Nov 1998 15:05:08 -0600

> > What seems a long time ago Dan Espen wrote:
[snip] 
> keep  putting off since  we only have  .fvwm2rc and .FvwmAnimate right
 
I'll put in a second to this idea. It seems like the right thing to do.
Also, if we do something standard for themes, it could be the place to
stick all of the details.

[snip]
> doesn't   seem to be   applicable  to the  2  modules   I've tried  to

I wonder if we should do some collecting of what people all use it for.
All I use it for is to randomize some pixmaps.  Something I could do more
difficultly with PipeRead.  But perhaps we should consider making the
preprocessors work different?  say something like a modified Read command?
Or some global setting so the preprocessor will sift over any file read by
fvwm?  Perhaps some fvwmlib command to read config files that will
preprocess them?

Just tossing some ideas around.

-- 
Mike Tilstra                                   Tadpol
[email-masked]  http://www.tc.umn.edu/~tils0007/
   Sanity is the playground for the unimaginative.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].