minimized and stick windows

[Alexander Preisinger]

2013/5/15 Pekka Paalanen <ppaalanen at gmail.com>

> 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.
>
>
Yes that seems logical. So the update_state should then be a
request/suggest_state event?
It seems I am tainted by using tiling window managers, where they sometimes
forces the size.


> 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).
>
>
My Idea is that the client gets notified per shell surface and the client
can hide all windows
(for example we want to minimize the main window) or just the
requested/proposed window.

I will try get some basic implementation done, maybe I can reuse soreaus
code for this.


>
> Deja vu,
>
pq
>


Thank you for your time

Best Regards.


Alexander Preisinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130515/264903ef/attachment-0001.html>