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

[Jason Ekstrand]

On Fri, Mar 8, 2013 at 4:39 PM, Scott Moreau <oreaus at gmail.com> wrote:
>
>
> On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>>
>> Scott Moreau wrote:
>>
>>> "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.
>>
>>
>> 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!
>>
>> 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.
>>
>> 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.
>
>
>
> 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.

That's not really a good answer when we're talking about the core
protocol.  If this is so experimental, it should be added as a weston
extension, not to the wayland core.  Before we start adding things to
the wayland core protocol, we need to get it right.

Also, I think I have to agree with Bill that this is a bit simplistic.
 The clients should have control over how things get minimized.  Also,
we probably don't want to simply unmap the surface.  As I understand,
unmapping is currently done by removing the buffer from the surface.
Many desktop environments have a window preview in the switcher or
somewhere else.  If you want to be able to preview minimized windows,
it needs to remain mapped.

I guess I don't necessarily have a problem with the events/requests
specified, simply that I think thinks need to be clarified and thought
out more.  For example, does the compositor send a minimize event to
the client and expect it to minimize windows or does it simply
minimize it?  I don't think we want the compositor hiding client
windows without letting the client override it.

I can provide more thoughts later, but there's my initial thoughts.
--Jason Ekstrand