Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!stan!garya
From: garya@stan.com (Gary Aitken)
Newsgroups: comp.windows.x
Subject: Re: Proposal -- UnmapRequest event type
Message-ID: <227@stan.com>
Date: 1 Sep 88 18:16:58 GMT
Organization: Solbourne Computer Inc., Longmont, Co.
Lines: 56


     It is not reasonable to pretend that a wm can prevent a client window
     from being unmapped.  What should happen, for example, when a client
     connection disappears?

The wm would not prevent the client window from being unmapped.
It would simply delay the unmap, just as it delays a map.
When a client connection disappears, the wm can handle it just as
it does now via destroy operations.

     If the user actually clicks twice on the client window (i.e. before it
     is unmapped), then both events will go to the client window - even if
     the client does an Unmap before reading the second event.  If the
     client manages to unmap the window before the second input event is
     seen by the server, then the wm will receive the UnmapNotify event
     before it receives the input event.  Either way, there's no problem
     as long as the server is working correctly.

As you observe it IS possible to have one of the events go to the wm.
The client unmaps the window before the server sees the second input
event.  There is a problem, in that it requires the wm to maintain its
own copy of the state information for the client window, based on 
the serialization of the events it sees from the server.
In this case:
	Wm gets an UnmapNotify
	Wm Unmaps its window
	Wm gets buttonpress/release
	Wm has to check that window is in fact unmapped, and button
	press/release should be ignored.

     ? Either the event was destined for the client window (and will go to
     the client) or it wasn't.  The wm should be smart enough to filter
     events occurring in unusual regions of it's frame windows.

I guess this is a design philosophy question.  It seems to me that
the event mechanism should be designed to make it easy to write
good software on top of X.  The MapRequest and related events were
included in the protocol specifically to allow for the implementation
of window managers.  The set is incomplete, in that a full set of
request events would mean that a wm does not have to keep track of
state information, and can simply trigger off of events, as any normal
client would.

     Latency is unavoidable in a network environment.  If you find the
     effect objectionable, you may discover that the connection between
     the wm and the server has to be the fastest one available to you
     (e.g. run them on the same host).

I run the wm on the same host (Sun 3/60), using unix:0 as the display.
The behavior is not due to network transmissions.  It is not a matter of
delays.  The server does the unmap of the client window, and the server
repaints the background for the wm window which is behind it.  No
amount of speedup will solve that problem.  The server is simply doing
what the protocol says it should do.  The display will always flash the
background of the underlying window when the covering window is unmapped;
the underlying client windows will subsequently be repainted only
after the wm unmaps its window.