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

[Scott Moreau]

On Fri, Mar 22, 2013 at 7:09 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> The underlying problem is that if a window is full-screen or maximized, and
> you minimize it, then un-minimize should put it back to full-screen or
> maximized. Thus un-minimize cannot be the "normal" state.
>
> The compositor could track the previous state and set that but then the
> client can't change the previous state while minimized.
>
> The proposed "un-minimize request" means the compositor does not know what
> state will result after the un-minimize.
>
> I think this can be solved by merging all these states into a single integer
> as bits:
>
>         MAXIMIZED = 1;
>         FULL_SCREEN = 2;
>         MINIMIZED = 4;
>         ...
>
> The rules are that if MINIMIZED is on then it is minimized, and the other
> bits are ignored. If not then FULL_SCREEN is on it is fullscreen and
> MAXIMIZED is ignored. Etc.
>
> The compositor can send an event to a surface saying that the state should
> change to a new set of values. Un-minimize just means it turns off the
> minimize bit and sends the new value.
>
> The client can send commands changing the state of surfaces. If it wants to
> turn off maximize while minimized, it just turns off the bit.
>
> This has a number of advantages:
>
>  1. greatly reduces the api count
>
>  2. Easy to add some new "state" to existing shell api
>
>  3. All plausable implementations of clients and shells I can think of would
> end up storing a set of flags just like this anyway and tracking the state.

I don't know what your problem is but you simply do not read or think
about anything you type, do you? You are wasting people's time here,
please find something better to do with yours. I am not going to be
using a single semantic you state because you're assumptions make it
sound like your word is absolute when it is in fact frivolous and
largely unnecessary. If you want it done your way, then write it
yourself.