[PATCH weston] toytoolkit: avoid redrawing a window between when it asks to be maximized and when it gets the configure

[Bill Spitzak]

Though I can see this saving an unnecessary redraw of the small window, 
this really should not produce such a bad frame.

If the client draws the "small" window then it will send a "small" 
buffer size to the compositor. The compositor can tell that this is not 
the "large" window and therefore it can put it at the old position (or 
possibly ignore it, but that might be a problem).

I can't seem to locate it now, but I thought the client actually sent a 
request saying it was now drawing the maximized window (as opposed to 
the request that it wants a configure event to get the size to make the 
maximized window). This would be much more reliable than just having the 
compositor look at window sizes.

The only glitch should be that you may see the button un-press on the 
small window, then it change to the large window. If that is not wanted 
then toytoolkit should keep the button pressed down while waiting for 
the configure. This should be done by making the widget actually draw in 
a down position, not by blocking updates like this is doing. Otherwise 
animation in the window will stop until the maximize happens, which 
makes the software look a bit dated...

MoD wrote:
> This patch is intended to resolve a bad frame that is visible when maximizing 
> toytoolkit programs by clicking the maximize button in their decorations. The
> issue, as far as I can tell, is that toytoolkit queues a draw to restore the
> button to its unclicked state at the same time it asks for its shell surface to
> be maximized. It then ends up drawing a small window on a large, maximized
> surface in the top-left corner of the screen. This patch adds a flag to the
> window which indicates that a resize has been requested but not received, and
> avoids drawing until a configure is received.