> It's really complicated, but let me try to explain what's going > on, in case we need to understand why I made the current patch - > at some time in the distant future.
[Very thorough and enlightening explanation skipped.] > Duh. > > Obviously vmplayer cannot handle this strange situation and ends > up with no window mapped. Thank you for this comprehensive explanation including references for further reading (ICCCM2). > As far as I understand it, HandleUnmapNotify() is broken at least > since the day in 1998 when the fvwm sources were moved to CVS. > I've spent much time thinking about this, reading the ICCCM2 and > the Xlib manuals, and now I'm convinced that HandleUnmapNotify() > must never unmap the client window itself. (The *icon* window is > a different story.) However, since there's no documentation about > this bit of code, it's hard to guess whether there are or were > really broken clients that needed this buggy window manager > behaviour. Anyway, if there are such clients, they won't work on > any modern window manager. > > Over the years there were several patches to fix problems caused > by unmapping windows in HandleUnmapNotify, but none of us ever > figured out the real bug for more than fifteen years. :-/ So this fix of yours really seems to be a big step. How would you judge its behavior concerning stability and side effects: Would it be to risky to use it right away in a production system, aka "testing under wild life conditions"? Juergen
