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

[Scott Moreau]

Hi Jason,

Thanks for your reply.

On Sun, Mar 17, 2013 at 7:24 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> 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.

This series provides a complete example implementation in weston.
Maximize and fullscreen are part of wl_shell_interface. It wouldn't
make sense to put it anywhere else, than the same place as these
existing events/requests.

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

What do you mean by this? Is there something more to minimize than
either minimized/iconified or not?

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

Yes, we probably want to make sure that clients wont be starved for
frame events, which is the case currently when pulling the surface
from the render list. It does not do an official 'unmap' though, i.e.
it does not use the unmap call in the weston shell plugin.

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

Yes, this is another catch. Minimize actually doesn't require client
support, the compositor can just 'unmap' it (using the term loosely
here). It certainly could use more thought. The main thing is, we want
to test real-world use cases and make sure they behave as expected. So
far since rebasing, I've been testing and haven't noticed any real
issues other than lack of frame events sent to minimized clients. The
gh next branches for wayland/weston has this series all applied and
working, in case anyone would like to tinker with it.
>
> I can provide more thoughts later, but there's my initial thoughts.

Thanks again for your concern.

> --Jason Ekstrand

Now I would like to take this opportunity to relate some new
information I have received from Kristian on IRC. It has come to my
attention that weston is not intended to be used as a real desktop
environment at all. From IRC:

<krh> the desktop in weston is a toy

Also these comments:

<krh> weston isn't going to be a full DE, starting a new DE is
specifically a non-goal of wayland
<krh> and I've always said that fleshing out wl_shell will have to
wait until we have at least one real DE to driver the work
<krh> otherwise it's all just going to be guesswork

This is unfortunate, because several things change. First, despite
Kristian showing interest in this window list series by listing it on
the patch queue emails
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007328.html,
he has unofficially rejected these patches in their entirety due to
the fact that they have DE-like goals in mind. Second, I personally
like weston and I think it has potential to become a DE in it's own
right with a little diligence and some time. Third, Kristian has
expressed no interest in the gh next series or the benefits that it
might provide. So, in light of these new developments, I am going to
continue working on gh next from a DE perspective, attempting to keep
rebased to official upstream repos and pull patches of interest from
the mailing list. gh next has made much progress in the few days since
the announcement. Thanks for everyone's help and as always, patches
welcome. I intend to make a separate post detailing the gh next
progress soon.

@Krisitian:

I am pretty discouraged by the stagnant activity of weston and by your
decisions to lead people on. I would like to request that you do not
post any more of my patches in the patch queue, because this makes me
think that these were definite patches of interest for inclusion to
the official repositories. I don't know why you would have people
believe, that their work is desired when in fact it is not. Further, I
don't think that any work can be considered guesswork when there is a
working implementation spanning several projects. If I am
misunderstanding anything here, please feel free to correct me.

- Scott