minimized and stick windows

[Mikko Levonmaa]

> I agree that the thread is a little daunting and gets
> political/personal towards the end.  But between Pekka, Jason and Bill
> I see concensus and I'll try to summarize here:
> 
>  - The server needs to be able to initiate state changes, but the
>    client is in control.  The server requests a state change but the
>    client ultimately has to set the new state and provide a new
>    buffer.  In case of maximize and unmaximize, the client has to
>    provide a new buffer before the state can change and in case of
>    minimize, the client may want to hide other windows as well as it
>    minimizes.
> 
>  - Discussion about whether states are orthogonal flags that the
>    client sets or if the client just sets the current state.  The
>    distinction is whether the compositor knows the full set of states
>    or only the effective state.  For example, if you maximize a window
>    and then minimize it, does the compositor know that it's maximized
>    and minimized or only that it's currently minimized?  I think the
>    compositor needs to know all the state, so that it's possible to
>    implement something like unmaximize while minimized.
> 
>    There's a catch: the current model (set_toplevel, set_fullscreen
>    and set_maximized) doesn't work this way, these requests always set
>    the current state, not a flag.  I think we can fit those into the
>    new mechanism: set_toplevel clears all states, set_maximized sets
>    maximized and clears fullscreen, and set_fullscreen sets fullscreen.
> 
>  - Enum vs set_minimized.  Do we add an enum with states and a
>    set(state) request or do we add set_minimized etc?  We only lack
>    set_minimized currently, but we also need events to let the
>    compositor initiate state changes, so we would have to add
>    request_maximized/minimized events as well as
>    request_unmaximized/unminimized.  If we add an enum of states
>    instead, we can add set and clear requests and request_set and
>    request_clear events.
> 
>    Using an enum also lets us add sticky and always-on-top as enum
>    values.
> 
>  - Visibility and frame events during minimized is orthogonal and up
>    to the compositor.  The compositor can keep sending frame events at
>    the full frame rate or throttle the application down to a few
>    frames per second for example.  But the compositor can do that at
>    any time, for example if the window is fully obscured by an opaque
>    surface, there's really no interaction with being minimized.
> 
>  - Stacking is an orthogonal issue.  Currently clients can't assume
>    anything about their stacking order relative to other clients, so a
>    compositor is free to unminimize surfaces to anywhere in the stack.
> 
>  - We've also talked about a request_close event that the compositor
>    can use to ask a client to close its window.  This useful for
>    closing from a window list or from something like the GNOME Shell
>    overview.  I think this is straight forward, though not directly
>    related to the state stuff here.
> 
> If we turn this into protocol, I think it will look something like this:


>   <interface name="wl_shell_surface" version="1">
> 
>     ...
> 
>     <enum name="state">
>       <description summary="surface states">
>         This is a bitmask of capabilities this seat has; if a member is
>         set, then it is present on the seat.
>       </description>
>       <entry name="maximized" value="1"/>
>       <entry name="minimized" value="2"/>
>       <entry name="sticky" value="3"/>
>       <entry name="always_on_top" value="4"/>
>     </enum>

Arent we missing the fullscreen from the above enum? Also the rationale
for me adding the default state (in the other thread) was that it would
indicate to the compositor that it is the "normal" state of the the app
i.e. when going from maximized/fullscreen to the default state the
compositor could remember the last size and propose that to the client.

>     <request name="set" since="2">
>       <description summary="Set the specified surface state"/>
>       <arg name="state" type="uint"/>
>     </request>

To me the word 'set' implies that this will happen and in some cases the
compositor might not honor this, so in a way it is a request. Perhaps
'request_state'?

> 
>     <request name="clear" since="2">
>       <description summary="Clear the specified surface state"/>
>       <arg name="state" type="uint"/>
>     </request>

This is a bit unclear to me. Does the compositor take some action after
this request or is the state just cleared on the compositors side? It
seems a bit open ended... if the client has set the state to say fullscreen
and then clears it will the surface still stay fullscreen.

>     ...
> 
>     <event name="request_set" since="2">
>       <description summary="request to set the specified surface state"/>
>       <arg name="state" type="uint"/>
>     </event>
> 
>     <event name="request_clear" since="2">
>       <description summary="request to clear the specified surface state"/>
>       <arg name="state" type="uint"/>
>     </event>
> 
>     <event name="request_close" since="2"/>
> 
>   </interface>
> 
> How does that look?

Excellent ;)

> 
> Kristian
> 
> 
> ------------------------------
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 
> End of wayland-devel Digest, Vol 32, Issue 73
> *********************************************