<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 8:48 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">Jasper St. Pierre wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hiding windows should not have any influence over the client, as many desktop environments, including Weston, want to show live previews for minimized or hidden windows in alt-tab or Expose-alikes.<br>
<br>
Also, it matches user expectations. If the user clicks minimize on a window, they want it hidden, and they mean it, not get bested with "surprise! You tried to hide me but I resist by mapping my subsurfaces elsewhere!"<br>

</blockquote>
<br></div>
The problem is that it makes window management very complicated, or limiting. This is why no modern applications use overlapping windows, instead doing their own tiled window layout inside one big window. They cannot get the window system to overlay windows correctly except for trivial temporary popups.<br>

<br>
A simple problem is a floating window shared by two main windows. Some parts of the compositor want to know that the floating window belongs to at least one main window (for instance to not show it in a toolbar). But the client does not want it to vanish when that window is closed, yet it should vanish when both windows are closed.<br>
</blockquote><div><br></div><div>Can you give a concrete example of such a case? Not because I'm assuming none exist, but because I want a specific example to evaluate and think about.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

This will require the client to tell the compositor that both of the main windows are parents, thus giving rise to a Directed Acyclic Graph of parents. I believe reliably updating this structure from the client is enormously more complex and error-prone than a simple tree. Also I suspect there are desirable window manipulations that cannot be described by a DAG and thus even more complex api must be provided in Wayland.<br>

<br>
Kristin has proposed that nothing be sent from the client to the compositor, I think he is worried about the api bloat this may cause.<br>
<br>
I feel that an intermediate solution that limits the data to a tree, since only a "set parent" api is needed to manage it. When a client requests that a window be raised or hidden then this tree causes children to do the same. But this is only done after a request from the client, so the client can first rearrange or delete the tree in order to get the behavior it wants. The main reason for this is that I think it is necessary so wayland clients can be displayed remotely on non-wayland systems that support such trees, otherwise remote display may be very blinky when users raise windows.<br>

<br>
Both of these however require that all decisions about window relationships be left to the client. There is no way around this, no matter how much you want to pretend otherwise.<br>
<br>
A client that fails to hide the window after the request and a timeout can get force-hidden, if you think this is a problem. But you cannot use misbehaving clients as a reason for designing an api, since there are a billion other ways a client can misbehave and you are not stopping them all with this one api.<br>

</blockquote></div><br></div><div class="gmail_extra">Like what?<br clear="all"></div><div class="gmail_extra"><br>-- <br>  Jasper<br>
</div></div>