minimized and stick windows

[Pekka Paalanen]

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

> 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?

Yup, something like that.

> It seems I am tainted by using tiling window managers, where they sometimes
> forces the size.

You can never really force a size.

You can tell a client with wl_shell_surface.geometry event, that this
window should be made at most this size. The client can choose a
smaller size, but should choose the largest size possible fitting into
the suggested size. Well-behaving clients will do just that.

If a client is not well-behaving, it will look like crap, and there's
nothing to fix that. But note, that well-behaving does allow a smaller
window than suggested, so you need to prepare for that in a tiling WM.

The "never expose global coordinates" property does allow a tiling WM to
deal gracefully with misbehaving clients, though. You can simply scale
the surface down to the size you really wanted, and the client will
continue working as if nothing strange happened. Only that one client
will look bad, but it still completely shows, and will not obscure
other windows.

> > 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.

Yeah.


Thanks,
pq