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 <ja...@jlekstrand.net> wrote: > > Hi Rafael, > > > > > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli <antogno...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel