Aire-One
/
awesome
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Handle synthetic UnmapNotify events 

According to the Inter-Client Communication Conventions Manual, if you want to
switch your window to withdrawn state, you unmap it and send a synthetic
UnmapNotify to the root window.

This synthetic event fixes a race condition. When you map and unmap a window
quickly, the map will generate a MapRequest for the WM but won't actually map
the window. Thus, the unmap will be discarded (-> window not yet mapped) and the
window stays map once the WM handles the MapRequest

Before this patch, awesome just ignored the synthetic unmap notify which caused
the bug to appear again. With this patch it doesn't happen anymore.

Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This commit is contained in:
Uli Schlachter 2009-12-28 16:23:19 +01:00 committed by Julien Danjou
parent 12d610ff2f
commit 8e672897cb
1 changed files with 17 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
event.c
View File

@ -665,11 +665,24 @@ event_handle_unmapnotify(void *data __attribute__ ((unused)),
if((c = client_getbywin(ev->window)))
{
if(ev->event == xutil_screen_get(connection, c->phys_screen)->root
&& XCB_EVENT_SENT(ev)
&& xwindow_get_state_reply(xwindow_get_state_unchecked(c->window)) == XCB_WM_STATE_NORMAL)
if(ev->event == xutil_screen_get(connection, c->phys_screen)->root)
{
if(!XCB_EVENT_SENT(ev))
{
/* A regular UnmapNotify, remove that client from our lists */
client_unmanage(c);
}
else
{
/* According to ICCCM 4.1.4 a client sends a synthetic
* UnmapNotify when it wants to switch to Widthdrawn state.
* We handle these by unmapping the client and waiting for the
* "real" UnmapNotify.
*/
xcb_unmap_window(connection, ev->window);
}
}
}
else
for(int i = 0; i < globalconf.embedded.len; i++)
if(globalconf.embedded.tab[i].win == ev->window)