[PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

On Fri, Mar 8, 2013 at 12:50 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> Scott Moreau wrote:
>
>  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.
>>
>
> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130308/c3f3e193/attachment.html>