On Fri, Sep 05, 2014 at 11:11:49PM +0100, Thomas Adam wrote: > On Fri, Sep 05, 2014 at 09:36:42PM +0100, Dominik Vogt wrote: > > (All these questions aim at finding out exactly what the > > WindowShade command does on your system, and what the difference > > is between shading and resizing windows manually.) > > It's to do with EWMH_SetWMState() -- that's the only difference, and > indeed in terms of CMD_WindowShade(), not calling that won't refresh the > contents. > > The call-chain looks like this: > > EWMH_SetWMState() -> ewmh_ChangeProperty() -> XChangeProperty()
Actually, in many places there's no XFlus() after these calls, so the change may be delayed somewhat. But that does not explain the symptoms. > I do not know why, in the case of the XChangeProperty() call happening > and fvwm receiving the PropertyNotify event for the EWMH-class of > events (it's not just windowshade, sticky also makes the window work > correctly), that the window is then magically refreshing its contents > and returning to normal. Well, the Ewmh stuff defines an atom for stickyness and one for shading, but nothing for iconify (as that information is already available from elsewhere). So I guess when the application receives a PropertyNotify event for one of these atoms it re-examines the window's state and concludes that ist should start redrawing again. Actually I don't understand all this crap logic. The real criterion is: If you receive an Expose event, redraw. If you don't receive one, don't redraw. A window that is iconified is unmapped and a window that is shaded is either hidden or unmapped. In both cases the window does not get Expose events and any special logic is superfluous. > That really is the culprit here---and indeed, WindowShading is no > different to resizing anyway, and having spent a while trying to debug > this, I can only conclude fvwm isn't to blame, nor do I want to dig > around in Chrome's internals. Thinking about it - shading in fvwm is very different from resizing in fvwm because when you shade a window, only the frame is resized, but the client window keeps its size. This is meant to prevent crazy redrawing during animated window shading. Furthermore the final size of the client window would be 0 pixels anyway, and the animation might make the window smaller than the requested minimum size. So I actually only move the window around in the frame during the animation without resizing it. Ideally the application wouldn't even notice that the window is shaded (shading would work *better* if there wasn't this stupid _NET_WM_STATE_SHADED atom). Well, I've probably made clear what I think of the Ewmh spec in the past. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
