On Mon, Jul 01, 2002 at 08:33:18PM +0200, Gerhard Hintermayer wrote:
> 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.
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, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Mon Jul 01 2002 - 18:33:58 BST