<div class="gmail_quote">On Fri, Mar 8, 2013 at 12:50 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">Scott Moreau wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The client doesn't need to be involved in a minimize action, unlike (un)maximize, it only needs a way to track its minimize state and request to be minimized. </blockquote> </div> No, please allow the client to decide exactly what surfaces to unmap in response to minimize. I need the ability to make floating windows that are shared by more than one surface. A request to minimize one of those surfaces can only be correctly handled by the client, unless you start sending incredibly complex DAG information from the clients to the server which I think should be avoided at all costs. Any workaround is going to make the floating windows blink which is against Wayland design principles. In general, the client must ALWAYS have last say over what surfaces are visible and what their stacking order is. The compositor NEVER NEVER NEVER changes this except in response to a request from the client. </blockquote></div> I don't know what you're talking about here but please see the comment in the last paragraph of the commit message: "Further, the term minimize is relatively subjective and defined by the implementation. Clients should not expect that minimized means the surface will be invisable to the user. There are several use cases where displaying minimized surfaces will be useful." Minimize can be handled differently by each compositor. The protocol does not define minimize explicitly. The important part is that the protocol is in place so that the compositor and clients can communicate minimize state information, not unlike maximize. The comment you're looking at does not represent any protocol restriction, it's merely a reminder that suggests a minimize surface might not be unmapped. We might want to view 'live' minimized surfaces in a window preview, graphical window switcher or scaling feature. It seems that you're misinterpreting this specific text but I'm not really sure what you mean. Just know that the weston implementation is a reference with working proof-of-concepts, exercising and demonstrating the protocol. A different wayland compositor can handle all of these events and requests differently. - Scott