Subject: Verson 1.1, animate icons

From: Dan Espen <[email-masked]>
Date: Fri, 16 Oct 1998 16:24:47 -0400

I have just checked in my latest changes to "animate icons".
(Same branch as before.)

The changes are:

1. A total  of  6 animations.  (I  grabbed the  latest animations from
Afterstep.)

2. Also from Afterstep, random animations.

3. Dynamic configuration.  There is a new flag in the module mask that
lets a   module receive commands   while  it is running,   so a module
doesn't have  to be restarted to change  its behavior.   (Actually, in
the past, fvwm2 had to be restarted to change a modules behavior.)

4. New commands "Stop" and "Save".

5. Builting menus. FvwmAnimate now   generates its own  configuration
menu during startup.  During   termination, it modifies its  menus  so
that all they can do is restart it.

6. Optional user  configuration file. During startup FvwmAnimate reads
commands from  all the normal  places plus the new  configuration file
that the save command creates.

This module now only  requires 1 command  to be added to  the .fvwm2rc
for it to be used.  (More likely you would add the 3 commands shown on
the man page.)  After that, no hand editing  of any configuration file
is needed to change its behavior or remove it.

(Zero configuration commands should be coming soon.)

In order for  the builtin menus to work  correctly, you need the patch
to builtins.c that makes DestroyMenu work.

Animate  icons adds new capabilities  to the  module interface.  There
are 2 documentation files  in  the source tree "docs/modules.tex"  and
"docs/modules.html"  that document the module   interface.  So far,  I
have been unable to install any version of "tex".  (As I remember, all
of the packages I found required root access.)

I would prefer to just update the html, and remove/ignore the tex.

I'm  soliciting  opinions about what  should  be done with  the module
documentation.

One more note. Currently,  animate icons only  works when the  builtin
icon  box is used.  If  you use "FvwmIconbox", or "FvwmIconman", there
is no animation.   I believe the   owners of these modules could  make
some fairly simple changes that would enable animation even when these
modules are used.

--
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: Maciej Stachowiak <[email-masked]>
Date: Fri, 16 Oct 1998 16:46:42 EDT

> of the packages I found required root access.)

Would you mind explaining the changes to the module interface briefly
on the list? Are they binary compatible with old modules? Source
compatible?

BTW, I have been seeing a lot of changes both to the interface of
builtins and/or the module interface, lately, both in the released
fvwm2 versions and in patches on this list. Are there any feelings
among active developers how stable these are to be considered, or when
they will be stabilized in preparation for a non-beta release of
fvwm2?

 - Maciej Stachowiak

---

From: Dan Espen <[email-masked]>
Date: Sat, 17 Oct 1998 16:25:27 -0400

Maciej Stachowiak <[email-masked]> writes:
> > "docs/modules.html"  that document the module   interface.
> > 
> 

All changes I've made  are intended to be  binary compatible  with all
existing modules.

Like   most  developers, I tend  to   think that  all  my  changes are
completely  stable and  bug free,  but  long years of  experience have
taught  me otherwise, so I  won't declare "animate icons" stable until
its been subjected to more testing than just my own.

I've done 3 significant things to the module interface:

1) I've    added  icon position  information     to the M_ICONIFY  and
M_DEICONIFY messages.

2) I've copied logic from Afterstep that lets a  module signal to fvwm
that fvwm    should not proceed with  its   processing after sending a
message to a  module until the module  sends  a message back to  fvwm.
The module adds  "M_LOCKONSEND" to the  "SET_MASK" command.  When fvwm
sends  any message to a module  with this flag set, it  does a read on
the modules pipe.   The module sends an UNLOCK  message as  soon as it
can.  In the case  of FvwmAnimate, this  is so the animation completes
before something else happens on the screen.

This adds the potential for a module locking up fvwm, but it also adds
the ability for modules to take on additional tasks, like for example,
providing frame  decorations.  By the way,  this logic is commented in
Afterstep indicating  that the author  didn't think the logic was done
completely  to his  satisfaction,  and that  a new   version  would be
coming.  My guess is that they plan to add a wait  for a response, and
if it doesn't come after some interval,  proceed without the response.
I'm waiting for the update, but haven't  seen it yet.  M_LOCKONSEND as
it is seems OK to me.

3) A module can now set the new flag,  M_SENDCONFIG.  This causes fvwm
to send module comands  to modules as  they are running, not just when
the modules  ask  for it, like the   old "GetConfigLine" allowed  for.
This allows fvwm   or any other  module  to talk to  any other  module
interactively.  I think  this can be very   useful within modules.   I
think the way FvwmAnimate is using it is just scratching the surface.

Exactly  how this affects scwm  is hard for  me to say.  Believe it or
not, I usually look  at the equivalent routines in  scwm before I make
my changes.  If I can find something equivalent in scwm, its my intent
to stay compatible with the  way its done  in  scwm.  In this case,  I
didn't see   anything in scwm  that  seemed   to  apply.  Actually,  I
couldn't locate "SET_MASK" in the scwm directory.  I do know you would
want to add icon position to the M_ICONIFY and M_DEICONIFY messages.

For a long time now, I have felt fvwm2 has been clean enough to be out
of beta.  Anyone of the last 10 releases has been good enough.  I know
there are still bugs, but there always will  be.  If I were making the
decision, I would take 2.0.47d, and one or 2 of the very small patches
and  go ahead to declare  it  to be non-beta.   I  don't think I would
include  any of  the more  substantial  patches that have  been posted
recently.

Oops, you did say "brief", didn't you...