Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
Hey,
On 8 August 2011 04:58, Valentin Ochs a...@0au.de wrote:
Just found http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
So apparently the help window wants to go into WithdrawnState, get
ignored by dwm, and draw its own icon or whatever right after being
mapped. Makes sense to me...
Reading the ICCCM standard, it does seem to be a bug in Mathematica:
The client should unmap the window and follow it with a synthetic
UnmapNotify event, but in fact all it seems to do is send the
synthetic event on its own. Not to mention that mapping the window and
then immediately asking to be withdrawn makes absolutely no sense.
For compatibility with obsolete clients, window managers should
trigger the transition to the Withdrawn state on the real UnmapNotify
rather than waiting for the synthetic one. They should also trigger
the transition if they receive a synthetic UnmapNotify on a window for
which they have not yet received a real UnmapNotify.
At the moment dwm makes no distinction between real and synthetic
UnmapNotify events, which means it does (for all intents and purposes)
seem to abide by the standard. But apparently Mathematica is broken.
Valentin's patch, although it apparently works, does quite abide by
the standard, in that it completely ignores synthetic UnmapNotify
events rather than setting the state hint appropriately. What I think
we should do is this:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Thanks,
cls
Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
On Mon, Aug 08, 2011 at 04:43:31PM +0100, Connor Lane Smith wrote:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Nope, still works fine.
--Valentin
Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
On 8 August 2011 18:10, Valentin Ochs a...@0au.de wrote:
On Mon, Aug 08, 2011 at 04:43:31PM +0100, Connor Lane Smith wrote:
if((c = wintoclient(ev-window))) {
if(ev-send_event)
setclientstate(c, WithdrawnState);
else
unmanage(c, False);
}
That way we abide by the standard, even if that means we set the state
to Withdrawn when it, well, isn't. I blame Mathematica for that one.
(Valentin, could you check whether this breaks the patch for Mathematica?)
Nope, still works fine.
I'm happy to incorporate those changes. Thanks for your investigation!
Cheers,
--garbeam
[dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
Mathematica 7 and 8, probably plenty of other versions, and maybe even some other retarded clients, send UnmapNotify events for their help windows right after they get created. dwm then forgets about the window and it's a huge pain in the ass to work with. Don't ask me why, I'm not drunk and stoned enough to be able to think like Mathematica devs. But I have a simple patch attached, which ignores all UnmapNotify events that don't come from the server. --Valentin diff -r 131d4f6a8a1e dwm.c --- a/dwm.c Fri Jul 29 20:01:22 2011 +0200 +++ b/dwm.c Mon Aug 08 05:21:44 2011 +0200 @@ -1761,7 +1761,7 @@ Client *c; XUnmapEvent *ev = e-xunmap; - if((c = wintoclient(ev-window))) + if((c = wintoclient(ev-window)) !ev-send_event) unmanage(c, False); }
Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events
Just found http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4 So apparently the help window wants to go into WithdrawnState, get ignored by dwm, and draw its own icon or whatever right after being mapped. Makes sense to me...
