fix for #1087220 (Wrong handling of XWithdrawWindow)
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:
parent
51f30a5a63
commit
8054e16fab
1 changed files with 12 additions and 5 deletions
|
@ -900,13 +900,13 @@ void Fluxbox::handleButtonEvent(XButtonEvent &be) {
|
||||||
|
|
||||||
void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
|
void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
|
||||||
|
|
||||||
|
|
||||||
WinClient *winclient = 0;
|
|
||||||
|
|
||||||
BScreen *screen = searchScreen(ue.event);
|
BScreen *screen = searchScreen(ue.event);
|
||||||
|
|
||||||
if ( ue.event != ue.window && (screen != 0 || !ue.send_event))
|
if (ue.event != ue.window && (!screen || !ue.send_event)) {
|
||||||
return;
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
WinClient *winclient = 0;
|
||||||
|
|
||||||
if ((winclient = searchWindow(ue.window)) != 0) {
|
if ((winclient = searchWindow(ue.window)) != 0) {
|
||||||
|
|
||||||
|
@ -929,6 +929,13 @@ void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
|
||||||
win = 0;
|
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());
|
||||||
}
|
}
|
||||||
|
|
||||||
}
|
}
|
||||||
|
|
Loading…
Reference in a new issue