nilix/fluxbox
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix for #1087220 (Wrong handling of XWithdrawWindow)

Browse source 
an XWithdrawWindow unmaps a window and sends a synthetic UnmapEvent after
that. when the second UnmapEvent arrives we have to set either the WM_STATE to
WithdrawnState or delete it. i decided for deletion so its absolutly clear
its not any longer under our control
This commit is contained in:
mathias 2005-01-10 09:04:46 +00:00
parent 51f30a5a63
commit 8054e16fab
1 changed files with 12 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
src/fluxbox.cc
View file

@ -900,14 +900,14 @@ void Fluxbox::handleButtonEvent(XButtonEvent &be) {
void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
BScreen *screen = searchScreen(ue.event);
if (ue.event != ue.window && (!screen || !ue.send_event)) {
return;
}
WinClient *winclient = 0;
BScreen *screen = searchScreen(ue.event);
if ( ue.event != ue.window && (screen != 0 || !ue.send_event))
return;
if ((winclient = searchWindow(ue.window)) != 0) {
if (winclient != 0) {
@ -929,6 +929,13 @@ void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
win = 0;
}
}
// according to http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
// a XWithdrawWindow is
// 1) unmapping the window (which leads to the upper branch
// 2) sends an synthetic unampevent (which is handled below)
} else if (screen && ue.send_event) {
XDeleteProperty(display(), ue.window, FbAtoms::instance()->getWMStateAtom());
}
}