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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
