Subject: Re: CVS dane: * FvwmAnimate/FvwmAnimate.c: Add ability to accept animate commands

From: Tim Phipps <[email-masked]>
Date: Fri, 03 Sep 1999 15:19:33 +0100

Dan Espen wrote:
> 
> > Brad Giaccio wrote:
> > > Dan, I almost have FvwmAnimate working with FvwmIconMan.  My only
> > > problem is on a deiconify I usually see the window get mapped then the
> > > message gets toFvwmAnimate.  Is there anyway that you know of to delay
> > > the deiconification until Animate finishes?
> >
> 
> I think I'd have to try it to be sure, but in module_interface.c
> any commands it gets from a lockonsend module, it hands off to
> HandleModuleInput which I think can make it wait for another lock on
> send, then return to the previous one.
> 

I just tried this with FvwmWinList and it does get things in the right
order. Unfortunately it also causes fvwm to lock up on a Recapture. I
don't know what's happening here but the changes I made were to send an
unlock immediately on every packet recieved by FvwmWinList except for
M_ICONIFY (the unlock goes out after the animate message in M_ICONIFY). 
I guess that since fvwm grabs the server during a recpature it means
that FvwmWinList locks trying to update it's window and can't receive
any more messages.

I'm just wondering if it would be easier to add a command to fvwm to
fill in the icon location of a particular NoIcon window.  FvwmWinList
could send this command for every button it had:

sprintf(icon_rectangle, "NoIconLocation %d %d %d %d", x, y, w, h);
SendText(fd, icon_rectangle, window_id);

There would be no need to change FvwmAnimate as it would think a normal
iconification had happened when it gets the numbers. There would be no
need to make FvwmWinList a LOCKONSEND module as it would send the
coordinates as soon as it created a button.  There would be no need to
hardcode a message to FvwmAnimate into FvwmWinList.  It would also
resolve the problem of what happens if two modules want to do NoIcon
animation, only one of them would win.

The only problem I can see with this is what happens if the module that
sets the NoIconLocation dies. Maybe a DefaultNoIconLocation command is
needed as well.

Cheers,
Tim.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Fri, 03 Sep 1999 10:41:14 -0400

> that FvwmWinList locks trying to update it's window and can't receive

One of those good news, bad news kind of things.

I'm also not sure what could be happening during recapture.

During  my last foray into  the  module interface  I noticed some code
related to lock on send, fvwm grabs and M_ICONIFY. I think it disabled
lockonsend during grabs.  (I don't think it was  my code.)  I wondered
at the time why the code was ignoring M_DEICONIFY.  Before we give up
on lockonsend, I think it would be worth changing this.

> SendText(fd, icon_rectangle, window_id);

The key concept here is FvwmWinList knows where its going to put
the icon, before the window is iconified?

I don't think that helps FvwmIconMan, or windows being created iconic.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Tim Phipps <[email-masked]>
Date: Fri, 03 Sep 1999 15:55:40 +0100

> the icon, before the window is iconified?

Yes, it will send the NoIconLocation command as soon as it gets the
M_ADD_WINDOW or the M_CONFIGURE_WINDOW message that tells it that the
window is a NoIcon style.  It would only send it if it creates a button
for the window.

> 
> I don't think that helps FvwmIconMan,

This isn't specific to FvwmWinList any of the winlist type modules could
do it.

> or windows being created iconic.

I'm not sure how a StartIconinc windows looks from the point of view of
a module. It might just work or it might give a spurious iconify at
start up.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Fri, 03 Sep 1999 11:19:34 -0400

> This isn't specific to FvwmWinList any of the winlist type modules could

Isn't FvwmIconMan empty until a window is iconified?
FvwmTaskBar presents the same problem.

I think FvwmIconBox is different, but I remember complaints about it
having icons for things that aren't iconfied yet.

> a module. It might just work or it might give a spurious iconify at

Agreed, something created iconic, doesn't need animation.

I'm still thinking lockonsend can do the job.

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 7 Sep 1999 08:21:48 -0400

> having icons for things that aren't iconfied yet.

Actually, IconBox, IconMan and WinList all display items regardless of
window state.

Brad 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Tim Phipps <[email-masked]>
Date: Tue, 07 Sep 1999 13:31:35 +0100

> Actually, IconBox, IconMan and WinList all display items regardless of
The change I made to FvwmWinList to have it handle animation of NoIcon
windows uses the style proposed by Dan i.e. FvwmWinList sends an animate
command to FvwmAnimate. I think this is a better way than my suggestion
of having fvwm maintain a NoIcon location: it doesn't go wrong if
FvwmWinList exits, it uses less memory and it doesn't require any
changes to fvwm.  The downside is that FvwmWinList has to become a
lock-on-send module which means more communication between it and fvwm. 
There may also be lurking bugs which cause a deadlock.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Tue, 07 Sep 1999 08:39:21 -0400

> There may also be lurking bugs which cause a deadlock.

I haven't yet looked at the feasibility, but I thought  if we got this
far,   (seems we  have), perhaps  fvwm  could  be told  that only  the
messages M_ICONIFY and M_DEICONIFY require a lockonsend response.

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 7 Sep 1999 09:54:27 -0400

> messages M_ICONIFY and M_DEICONIFY require a lockonsend response.

Tim, 
did something you did hear effect animations when WinList isn't running.
Right now if I iconify one of my icons it gets animated twice then
mapped.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 07 Sep 1999 15:06:19 +0100

> messages M_ICONIFY and M_DEICONIFY require a lockonsend response.
Yes it could, but if the modules were to be changed to only ack these
message and then for some reason we made another type of message require
ack's we would have to go through all the modules and make sure they
didn't deadlock.

Here's a thought:
*) Remove M_LOCKONSEND
*) Add a sibling to SetMessageMask(): SetSyncMessageMask() that tells
fvwm what messages are to be treated as though M_LOCKONSEND  is set.
*) WinList can then use SetSyncMessageMask(M_ICONIFY | M_DEICONIFY) and
only need to send an unlock on these messages.
*) Animate would use SetSyncMessageMask(M_ICONIFY | M_DEICONIFY |
M_STRING)

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 07 Sep 1999 15:09:39 +0100

> Right now if I iconify one of my icons it gets animated twice then

I don't think this is FvwmWinList. If it isn't running it can't send the
animate command. Do you have two FvwmAnimate's running? What is your
animate style?
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Brad Giaccio <[email-masked]>
Date: Tue, 7 Sep 1999 10:16:32 -0400

> animate command. Do you have two FvwmAnimate's running? What is your

You caught me I did have two running, how I don't know but there were
two running.

Brad

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 08 Sep 1999 09:40:29 +0200

> > > There may also be lurking bugs which cause a deadlock.

Hello,

I have a deadlock with FvwmWinList (and animation) in the following
situation:
- The only opened windows belongs to the WindowsSkipList.
since my FvwmWinList use it, WinList is not in my screen.
At this point every thing is ok.
- Then if I start a standard application, the application 
does not appear in the screen and I need to kill X to
get control on my machine (I presume that I've got a deadlock).

However, if I start WinList and some applications not in the 
SkipList  already run the animation work very well (and I like 
it very much !!).

Olivier

---

From: Tim Phipps <[email-masked]>
Date: Wed, 08 Sep 1999 14:19:52 +0100

> get control on my machine (I presume that I've got a deadlock).
I think what happens here is that FvwmWinList does an XMapWindow which
blocks waiting for fvwm to map the window border. fvwm broadcasts an
M_ADD_WINDOW packet for the FvwmWinList window but this blocks because
FvwmWinList is a lockonsend module.

I don't know what the fix for this is.  Making FvwmWinList drop the
LOCKONSEND flag when unmapping won't work because it is prone to a race
hazard (messages are asynchronous with X events).  Just ignoring
LOCKONSEND with M_ADD_WINDOW messages may work but it prevents animation
of window mapping which might be nice to do one day in FvwmAnimate.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Wed, 08 Sep 1999 13:57:24 -0400

> of window mapping which might be nice to do one day in FvwmAnimate.

To animate M_ADD_WINDOW we'd need another packet that wasn't associated
with a grab.

We have a choices:

a quick fix which eliminates M_LOCKONSEND for everything but m_iconify
and m_deiconify.  I think M_LOCKONSEND is still under control, we
can change it now, and then change it again later.

The change we discussed which sets a lockonsend mask.
I think I might be able to find time to do this, but I don't
want to start if you're going to do it.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 09 Sep 1999 11:12:28 +0100

> *) Animate would use SetSyncMessageMask(M_ICONIFY | M_DEICONIFY |

Scrap this idea, it won't work.  If some messages are not synchronous
they will end up in the queue. When a synchronous message is sent fvwm
will add the sync message to the end and wait until the unlock message
comes back. This won't happen until all the message have been processed
by the module and some of them might deadlock.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 09 Sep 1999 12:41:38 +0100

> > > I have a deadlock with FvwmWinList (and animation) in the following

I think I've fixed this: FvwmWinList waits for an expose event after
mapping it's window, removing the wait fixed the deadlock and I don't
think it breaks anything. I'll commit later.

> > FvwmWinList is a lockonsend module.

The map doesn't block but waiting for an expose deadlocks because the
expose won't happen until fvwm maps the parent window and that won't
happen until WinList handles lots of messages (M_CONFIGURE, M_NAME,
M_MAP) and that won't happen because WinList is waiting for an expose.

> can change it now, and then change it again later.

I don't think this makes deadlocks impossible, it may just make them
only happen with busy systems (messages buffered) which would make it
very hard to track down.

> want to start if you're going to do it.

This is just another way of having some messages synchronous and others
async.  I don't think it eliminates the chances of deadlock.  Messge
from fvwm must be processed in serial order and so there is no guarantee
that a sync message won't be appended to a queue that has other messages
in it that will cause a deadlock.

I think the fix is to leave M_LOCKONSEND as it is and to fix any modules
that cause deadlock.  Having all message be synchronous when
M_LOCKONSEND is set means that the message queue for that module will
always be empty which I think means that debugging deadlocks should be
simple (kill -QUIT the module and look at the last message).  Making a
module deadlock safe means making sure it only ever blocks in the
select() call that handles fvwm messages.  It means XSync() is not
allowed or things like WaitForExpose() or XNextEvent().

Is it possible to put a timeout in the fvwm sync message sending?

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 9 Sep 1999 08:37:15 -0400

I'm just thinking outloud here.  But how about this.  We modify
FvwmAnimate,by putting all of the animation stuff into fvwm/libs.  Then
have each module that cares (IconMan, WinList, TaskBar, Wharf) call the
function to animate then in a similar style to FvwmTheme, Animate can
simplly be a controlling module that dictates look and feel, and passes
a message to fvwm, which would pass it to all modules.  Now I realize
there may be problems with this method as well, but the chances of us
finding all possible deadlock cases is going to be pretty slim.

Any thoughts?

Brad

---

From: Dan Espen <[email-masked]>
Date: Thu, 09 Sep 1999 09:54:44 -0400

> finding all possible deadlock cases is going to be pretty slim.

I think  we should  try  as  hard as we   can to  keep  something like
FvwmAnimate out  of the core.     Its pretty frivilous.   Putting  the
animation logic in fvwm/libs would be a last resort.

> Is it possible to put a timeout in the fvwm sync message sending?

Thats seems to be what the fvwmSelect function gives us.
Seems like a good idea.

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 9 Sep 1999 12:05:29 -0400

> animation logic in fvwm/libs would be a last resort.

Well its not anymore fribilous than the Gradient drawing algorithms.
This would basically only be code that get called if I ask for
animation.  The binary for Animate is only 41K so I don't really see
code bloat as an argument against.  But if you want to keep fighting
deadlock bugs, I'm all for it and will do my best to help you squash
them.

Brad

---

From: Tim Phipps <[email-masked]>
Date: Fri, 10 Sep 1999 10:00:11 +0100

> function to animate then in a similar style to FvwmTheme, Animate can

This won't stop deadlocks. Modules that want to do animation at iconify
time will still have to be LOCKONSEND modules.  The last deadlock with
FvwmWinList was caused when a window was created and the in the set of
messages that fvwm sends on window creation was a message that caused
FvwWinList to wedge. This blocked the handshaking of the last few
messages and so fvwm blocked. It had nothing to do with iconify
animation.

If we could put a timeout on sending messges to LOCKONSEND modules it
would be useful if a timeout caused the module to be killed with a core
dump and a report from fvwm about what message type it was sending.

Cheers,
Tim.