<br><br><div class="gmail_quote">On Fri, Aug 10, 2012 at 7:47 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">
This looks really messy and still makes the assumption that the only reason for "edges" to be removed is because of "maximize". It is also completely different than how "fullscreen" is done, even though that should be identical except the "titlebar" is also removed for fullscreen.<br>

<br>
Based on the latest changes to the shell api, I feel the following must be added:<br>
<br>
1. The "content" region. This is the part of the window that does not include the "edges". However it *does* include the titlebar. Imagine the "part of the window you see when it is maximized". This is different and smaller than the input region</blockquote>
<div><br>No it isn't. The input region and your theoretical content region are exactly the same.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and should be specified by clients using a new api very similar to how the input and opaque regions are specified. Shells need this information to property implement snap-to-edge (where the edge is of another window, a panel, or an output),</blockquote>
<div><br>No it doesn't. We can do snap-to-edge for any edge with the input and surface areas known already.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 and to implement maximizes other than the full-screen maximize (ie vertically-only). It also means "maximize" is not a special state, instead the shell just resizes the surface so that the contents fill the output.<br>
</blockquote><div><br>This doesn't really have anything to do with what we're talking about here.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. When the shell tells a client to configure a window, it should communicate both a size for the surface image, and the bounding box of the content region in this new size.</blockquote><div><br>It already does this and it's called the input region.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This bounding box will always be the same distance or closer to the edges of the surface (ie it is only used to clip edges, not to make them thicker). This allows clients to know that edges are clipped so they do not place any important controls there, and they can adjust their graphics to take into account the clipping (for instance not drawing rounded-corner shading for a clipped-off rounded corner). It will also save some memory and rendering time by clipping these off the allocated image buffer.<br>
</blockquote><div><br>You are over-thinking this far too much. We don't need any of this.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ideally this new box should be added to the configure event and we should just require clients to obey it. If this is not allowed due to the api being frozen, it could be a different event, but it suffers from the ugly fact that the size sent with configure is not the actual size the surface should be (because that would make a client that does not clip the edges make the window too small when maximized).<br>
</blockquote><div><br>It's the same as the input region which we already have.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Fullscreen: somewhat unrelated, but the shell should be able to directly tell clients to "remove all decorations". Currently this is tied into the fullscreen request from a client. This is necessary so shells can force a client to fullscreen. It is also needed for embedding one wayland client in another. It may also be useful for displaying wayland clients on legacy window systems that make it very difficult to remove their own decorations.<br>

</blockquote></div><br>This sounds like a bunch of stuff we don't need. The client will have special cases for decoration flags such as maximized and none.<br><br><br>To make your point more specific, why not submit a patch implementing what you think should happen? I'm not really sure why you're doing this whole write up without any code to show. Further, we should strive to make initial implementations as simple as possible and not try to over complicate it. That said, there is a bug where the input or opaque region may be invalid at any given time. My snap implementation built on top of the v3 patch here works around the issue but we still need to restructure the way input and opaque regions are handled before advancing on this.<br>
<br><br><br>Scott<br>