Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: Proposal -- UnmapRequest event type
Message-ID: <8808311216.AA14355@LYRE.MIT.EDU>
Date: 31 Aug 88 12:16:54 GMT
References: <225@stan.com>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 49


     Date:  30 Aug 88 20:43:34 GMT
     From:  stan!garya@boulder.colorado.edu  (Gary Aitken)

     Seems to me the X11 protocol should include an UnmapRequest event type,
     corresponding to MapRequest.  Example of why:

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?

     Window manager has reparented the main client window to its own window,
     which essentially underlies the area of the client window.
     User clicks twice on client window.
     Client triggers off first click, and unmaps the (client) window.
     Server unmaps client window.

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.

     The wm can maintain it's own copy of the window state information,
     and discard input events for wm windows which correspond to unmapped
     client windows.  (The wm will have already processed the UnmapNotify
     event by the time it gets the button click/release.)

? 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.

     Both of these are pretty poor solutions.  In particular, they do not
     remove the jerky display appearance caused by the client window first
     being unmapped, followed by the wm window.

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).

     While on the subject, Jim Healy (article #45??) brought up the problem of
     how does a client know when it's base level windows have been moved by a
     window manager.  Is there any proposal underway which requires a wm to 
     notify clients via XSendEvent of a configure notify when the wm moves the
     client?

Yes.