garya@stan.com (Gary Aitken) (08/31/88)
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
swick@ATHENA.MIT.EDU (Ralph R. Swick) (08/31/88)
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.garya@stan.com (Gary Aitken) (09/02/88)
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.