On May 15, 2013 9:37 PM, "Mikko Levonmaa" <<a href="mailto:mikko.levonmaa@gmail.com">mikko.levonmaa@gmail.com</a>> 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 > > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > > > > > > End of wayland-devel Digest, Vol 32, Issue 73 > > ********************************************* > _______________________________________________ > wayland-devel mailing list > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> Hope that helps, --Jason Ekstrand