Subject: Re: FVWM: DeIconify does *not* deiconify iconified windows

From: Gerhard Hintermayer <[email-masked]>
Date: Mon, 01 Jul 2002 20:33:18 +0200

Dominik Vogt wrote:

> 
> Okay, it took me quite some hours to figure this out:  It's *not*
> a problem with fvwm.  Although you can't see it, the application
> window *is* mapped.  It's just that tk thinks it is not visible
> and thus does not draw anything into it.  I couldn't find
> anything that fvwm is doing wrong.  Actually, I couldn't even
> find any difference in the requests that wish sends to fvwm -
> regardless if the deiconify line is in the code or not.  I think
> there must be a bug in wish.
> 

Could it be the case,that fvwm>2.2.5 delivers events to "wish" as a different
type. The update command distinguishes between all events (no parameter) and
idle callbacks (parameter idletasks). Using no parameter for the update there
are no problems (if I remember correctly), but that aim't no the way to go.
Seems like good old 2.2.5 delivers events the do get processed as idle
callbacks, whereas all follow versions don't. I have to take a look at the tcl
sources to get an idea, which event's are put into which category.

-- 
Gerhard Hintermayer
http://www.inode.at/g.hintermayer

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Tue, 2 Jul 2002 01:34:45 +0200

> sources to get an idea, which event's are put into which category.

Fvwm does not send any events to the application (well, almost,
there are some cases, but these don't play a role here).  The X
server does it automatically.  I'm sure the problem is timing
related:  Fvwm receives *exactly* the same exents in both cases
and thus behaves the same.  But wish interprets the events
differently.  Since the outcome seems to be somewhat random, it's
very likely that timing plays a role.  Applications should not be
written in a way that relies on a specific timing.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Sat, 6 Jul 2002 23:37:54 +0200

On Tue, Jul 02, 2002 at 01:34:45AM +0200, Dominik Vogt wrote:
> there are some cases, but these don't play a role here).

I am mistaken here.  These events do play a role.  For some reason
(I think to make some other application happy when it starts as an
icon), I forced an UnmapNotify event being sent to the application
before the icon was created.  I'm mystified as to why wish thinks
the UnmapNotify negates the MapNotify that arrives later.
Maybe it processes events out of their proper order.  Anyway, I've
added a faked MapNotify event that is sent right before the
UnmapNotify, and wish seems to be happy now.

Please consider reporting this problem to the wish developers.  I
still think it's a bug in there that may well show other symptoms.
In general processing events out of order - especially events
that are of related types like MapNotify and UnmapNotify - is
dangerous.  It usually works as long as not much is happening on
the desktop, but when things get really busy it may cause
problems.

Bye

Dominik ^_^  ^_^

---

From: Gerhard Hintermayer <[email-masked]>
Date: Mon, 08 Jul 2002 15:31:25 +0200

> the desktop, but when things get really busy it may cause

I did submit a bug entry at tcl.sourceforge.net and quoted some of your postings 
there, hope that'll be ok. The Bug entry #578569 and any comments to it can be 
viewed at
http://sourceforge.net/tracker/index.php?func=detail&aid=578569&group_id=12997&atid=112997

Gerhard