minimized and stick windows

[Pekka Paalanen]

On Wed, 15 May 2013 14:20:21 +0200
Alexander Preisinger <alexander.preisinger at gmail.com> wrote:

> Hello,
> 
> I thought a bit about it and like to present my ideas.
> I mainly thought about it from the shell/compositor site when I like to
> minimize, maximize surfaces from keybindings, like in some window managers.
> 
> For example the client can still request minimize, maximize, fullsrceen and
> toplevel actions, but now the compositor responds with an state_update
> event.
> The compositor can also send this state_update when the compositor likes
> change the window on it's own (like some task bar or compositor key
> bindings).
> The client can then save the state and act accordingly (like hiding same
> menus if maximized or fullscreen).
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 3bce022..e0f2c4a 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -811,6 +811,14 @@
>        <arg name="output" type="object" interface="wl_output"
> allow-null="true"/>
>      </request>
> 
> +    <request name="set_minimized">
> +        <description summary="minimize the surface">
> +    Minimize the surface.
> +
> +    The compositor responds with state_update event.
> +    </description>
> +    </request>
> +
>      <request name="set_title">
>        <description summary="set surface title">
>         Set a short title for the surface.
> @@ -867,6 +875,30 @@
>        <arg name="height" type="int"/>
>      </event>
> 
> +    <enum name="state">
> +      <description summary="different states for a surfaces">
> +      </description>
> +      <entry name="toplevel" value="1" summary="surface is neither
> maximized, minizized or fullscreen"/>
> +      <entry name="maximized" value="2" summary="surface is maximized"/>
> +      <entry name="minimized" value="3" summary="surface is minizimed"/>
> +      <entry name="fullscreen" value="4" summary="surface is fullscreen"/>
> +    </enum>
> +
> +    <event name="state_update">
> +        <description summary="update surface state">
> +    Tells the surface which state is has on the output.
> +
> +    This event is sent in respons to set_maximized, set_minimized or
> +    set_fullscreen request to acknowledge the request. The client can
> update it
> +    own state if it wants to keep track of it.
> +
> +    The also compositor sends this event if itt wants the surface
> minimized or
> +    maximized. For example by clicking on a task list item or compositor
> key
> +    bindings for fullscreen.
> +    </description>
> +        <arg name="state" type="uint" summary="new surface state"/>
> +    </event>
> +
>      <event name="popup_done">
>        <description summary="popup interaction is done">
>         The popup_done event is sent out when a popup grab is broken,
> 
> 
> I don't know about multiple window applications and maybe missed some other
> use cases, but I hope this isn't too wrong of an idea. At least this should
> hopefully not break the protocol too much.

If I understood right, here you have the client asking the compositor
for permission, and then the compositor orders the client to be in a
certain state and will compose it as such, regardless of what the client
actually draws.

This won't work, fixing the races it causes will complicate the
protocol and cause roundtrips.

The client draws its window, hence the client is in charge of how it
looks, and the compositor cannot force that.

Hence, it must be compositor proposing to the client that it should
e.g. maximize. It the client does that at some point, perhaps first
sending a few new frames since it was animating, the client will tell
the compositor it will now go maximized, and then the very next frame
it draws will be maximized. This avoids flicker.

Minimize is a little special, since the client does not need to react
specially for it to look right. For everything else it will need to.
Actually, if you think about a multi-window application, minimize needs
to work the same way, so that application can hide all relevant
windows (but maybe not *all* windows).


Deja vu,
pq