<br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Scott Moreau wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"Further, the term minimize is relatively subjective and defined by the<br>
implementation. Clients should not expect that minimized means the surface<br>
will be invisable to the user. There are several use cases where displaying<br>
minimized surfaces will be useful."<br>
<br>
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.<br>

</blockquote>
<br></div>
Actually perhaps I am misunderstanding it. Does it just send an "unmap request" from the shell to the client? From the code it seems to cause the compositor to stop showing the minimized window without any indication being sent to the client at all, which I absolutely disagree with!<br>

<br>
If in fact the window will not vanish until the client responds to the unmap request, that will allow the client to atomically unmap child windows if wanted.<br>
<br>
I'm not sure if that is a good idea to have the "unmap request" without an indication that it is due to a minimize, though. Maybe there are multiple reasons for an unmap request and clients may want to respond differently to them.<br>
</blockquote><div><br><br>I am not really sure what you are talking about but I'm also not sure I have time for it. The fact is that this is only a basic implementation to exercise the new protocol. If you would like to contribute code, the policy is that patches are welcome. A working implementation of what you think is better might also help to illustrate your points better.<br>
<br>- Scott<br></div></div><br>