minimized and stick windows

Wed May 15 19:57:55 PDT 2013

On May 15, 2013 9:37 PM, "Mikko Levonmaa" <mikko.levonmaa at gmail.com> wrote:
>
> > 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.

Fullscreen is a bit special as it requires other arguments (mode and
output). You cant merely set it as a flag. It should probably be considered
as a different mode all together. More specifically, the flags only apply
to toplevel surfaces. (Maximized will require a little work to keep
backwards compatibility.)

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

The client is setting surface flags (perhaps "unset" would be better than
"clear" below). Exactly what the compositor does will depend on a
precedence order. Kristian didn't define it above but it shouldn't be too
hard to do.  That said, the order should be well documented.

Why wouldn't the server respect the flags? Also, when this request is
handled, the flag is set. The only strange thing the compositor can do is
to do something unexpected with the flags.

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

The compositor will change how it handles the surface to the set flag with
highest priority.   Suppose minimize is higher priority than maximize and
both are set.  If the client unsets maximize then nothing will happen
because minimize is still set and it has the higher priority.

It is worth noting here that some flags may not really play into the
priority order.  For instance, an on-every-workspace flag (is that what is
meant by "sticky"?) wouldn't really have anything to do with maximize or
minimize at all.  Some flags may just be hints to the compositor or window.
Another example of this would be a "tiled" flag for tiling WM's.

> >     ...
> >
> >     <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
> > *********************************************
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Hope that helps,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130515/271d18b0/attachment.html>