minimized and stick windows

[Kristian Høgsberg]

On Mon, May 13, 2013 at 06:14:46PM -0300, Rafael Antognolli wrote:
> Hi Jason,
> 
> On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > Hi Rafael,
> >
> >
> > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli <antognolli at gmail.com>
> > wrote:
> >>
> >> Hello,
> >>
> >> I've been looking the Weston code relative to maximized windows, and
> >> it seems that the respective code for minimized windows wouldn't be
> >> hard to implement.
> >>
> >> The questions are: are there any plans to add it? Is there someone
> >> already working on it? If not, would it be OK if I start submitting
> >> patches to try to add support for this?
> >
> >
> > A month or two ago, Scott Morreau was working on it.  However, his work
> > never made into weston for a variety of reasons.  Personally, I'm glad to
> > see someone interested in working on it again because it's something that
> > wayland will need eventually.
> >
> > The place to start on it is probably with the following e-mail and the long
> > string of replies:
> >
> > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html
> >
> > There was quite a bit of discussion about how to handle it from a protocol
> > level, but Scott never made an actual version 2.  I'd suggest you start by
> > reading the chain of e-mails (it goes into April, not just March).  There
> > were quite a few suggestions in there that could be incorporated.
> > Hopefully, you can pick through the e-mail discussion and figure out what
> > the consensus was.  It'd be good to have a pair of fresh eyes look at it.
> 
> Thanks for pointing that out. I just went through the chain of
> e-mails, but I don't think there was a consensus there.
> 
> It also seems that the minimize implementation is a little more
> complex than just hiding surfaces and marking some flags. Which makes
> me not so comfortable doing an implementation without a consensus
> about what should be implemented, and with some orientation.
> 
> That said, I'm not sure I'm really going to take this task.

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>

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

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

    ...

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

Kristian