Re: [dev] [dwm] [patch] Fix for retarded clients that send unmapnotify events

Hey,

On 8 August 2011 04:58, Valentin Ochs <a_AT_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
Received on Mon Aug 08 2011 - 17:43:31 CEST