[PATCH 2/2 weston] toytoolkit: Don't draw shadows for maximized windows.

[Scott Moreau]

On Fri, Aug 10, 2012 at 7:47 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> 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.
>
> Based on the latest changes to the shell api, I feel the following must be
> added:
>
> 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


No it isn't. The input region and your theoretical content region are
exactly the same.


> 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),


No it doesn't. We can do snap-to-edge for any edge with the input and
surface areas known already.


> 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.
>

This doesn't really have anything to do with what we're talking about here.


>
> 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.


It already does this and it's called the input region.


> 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.
>

You are over-thinking this far too much. We don't need any of this.


>
> 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).
>

It's the same as the input region which we already have.


>
> 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.
>

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.


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.



Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120810/85546da8/attachment.html>