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

[Scott Moreau]

On Mon, Mar 18, 2013 at 3:29 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Scott Moreau wrote:
>
>> Note to Bill Spitzac: I find your posts to be often frivolous and
>> incoherent. I don't mean to be rude here but I have tried to consider
>> many of your points and you often go on long tangents about some
>> problem that doesn't exist in reality or a highly isolated use case.
>> Many times I see your postings as a frivolous spec in a ml paragraph
>> of how you think something should work. My point here is, if you want
>> something to work a certain way, then write the code. This way, people
>> can review and comment on your code (not your random comments) or you
>> can just use it for yourself. I would like to ask that if you do
>> respond, please put in the time and effort to make your thoughts
>> coherent and in the scope of the wayland reference compositor.
>
>
> I have gotten zero feedback (not even somebody saying "this is incorrect")
> for any patches I have submitted so far. I have to say this is a little
> discouraging.

Yes I have found the lack of feedback for patches on the list very
discouraging. It is discouraging to all community members who would
like to contribute.

>
> I agree my posts tend to specify an implementation rather than the desired
> results, though it would seem that source code is going even further in that
> direction.

Right. The point is, that if you have something laid out in your head
how exactly it should work, then rather than trying to convey these
explicit details to another human over a mailing list and expect them
to read your view, and then accept it as correct and start coding it
for you, the way you dictate, is completely unrealistic. If you
already know precisely how it should work, then you are the one that
should write the code.

>
> I can try some pictures to show what I think the minimize must be able to
> support:
>
> #1:
>    +--------+
>    |        |
>    | MAIN1  |---------+
>    |        |         |
>    |    +--------+    |
>    |    | DIALOG |    |
>    |    +--------+    |
>    +--------+ MAIN 2  |
>            +----------+
>
> After "minimize" of MAIN1, this is the desired result:
>
> #2:
>            +----------+
>            |          |
>         +--------+    |
>         | DIALOG |    |
>         +--------+    |
>            |  MAIN 2  |
>            +----------+
>
> After "minimize" of MAIN 2 this is the desired result:
>
> #3:
>         <blank>
>
> The API must be designed so that no composite other than the initial and
> final is ever produced, even for a split second, for each of these
> transitions. By "other composite" I mean any different stacking order or any
> where the set of visibility of surfaces is different.
>
> For instance if minimize hid the dialog but the client could put it back,
> this would make the transition from #1 to #2 have an intermediate composite
> where MAIN 2 was visible but not the dialog.
>
> If the compositor did not hide the dialog but the client did it in response
> to the minimize, then the transition from #2 to #3 would result in an
> intermediate display where only the dialog is visible.
>
> I believe the only solution is for the compostior to send minimize-request
> to the client, and the client then has to minimize the window (and the
> dialog if it wants) and then to a commit to make it atomic. However I agree
> that trying to specify a solution would be better with source code.
>

Patches welcome.

- Scott