Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!stan!garya
From: garya@stan.com (Gary Aitken)
Newsgroups: comp.windows.x
Subject: Proposal -- UnmapRequest event type
Keywords: window manager, maprequest
Message-ID: <225@stan.com>
Date: 30 Aug 88 20:43:34 GMT
Organization: Solbourne Computer Inc., Longmont, Co.
Lines: 57

I posted the following several weeks ago but received comments only from
local users.  I suspect it didn't get out to the world as intended.
My appologies if you've seen it.  Someone outside (Jim Fulton?) please
comment so I know it got out.

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

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.
Window manager's window receives the 2nd click/release, because the
server gets the 2nd click before the wm has processed the UnmapNotify
generated by the client's Unmap.  If window manager interprets click
on it's window as meaning something, user gets surprise.

The same problem arises with keyboard input, if the keyboard events come
in fast enough.

There are at least 2 work arounds that I am aware of:

The wm can query the client window state every time it gets an input event,
to make sure the window is visible.  This will slow everything down
a bunch.

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

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.

An UnmapRequest event type, which can be redirected just as a MapRequest
can, would solve these problems, since the client window would still be
mapped when the 2nd click occurs.  The wm would trap the client request
(i.e. client unmap would be converted to UnmapRequest), unmap the wm window,
then unmap the client window (Client window must be unmapped in case client
queries its state).

Similar scenerios can be constructed for other event types which
a wm uses via SubstructureNotify.  ReparentRequest and DestroyRequest 
would be particularly useful as well.

Comments?

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?

-- Gary Aitken

UUCP: ncar!boulder!stan!garya