Scott, Allow me to be a bit more specific as to what I am thinking. In general, I like the requests and events in the protocol, I just think things should be set out more clearly. The documentation given in the protocol isn't terribly specific as to how someone is supposed to implement it. From reading your code, it seems like you simply have this magic "minimized" state that you're trying to keep in sync. Unfortunately, it's not terribly clear.
Here is how I think I would have such a protocol work. (Perhaps this is what you intend, but, like I said, it's kind of hard to tell.) If the minimize event comes from compositor-side: 1. The compositor sends a "request_minimize" event to the client (or just "minimize", but I like the other a little better) 2. The client responds with "set_minimized" events on any number of top-level surfaces. 3. The compositor minimizes the top-level surfaces as requested by the client If the minimize event originates client-side: 1. The client sends calls "set_minimized" on any number of top-level surfaces 2. The compositor minimizes the top-level surfaces as requested by the client In this way the client remains in control of what windows get minimized etc. I think it also makes it more explicit as to when a window is/isn't max/minimized. I also like this addition because it allows for the possibility of server-side decorations. Not that those are going to be a for-sure thing, but allowing the compositor to relay these kinds of events to the client is very useful. Along these lines, a "request_close" event is probably not a bad idea. That said, I think things should be client-controlled not compositor-controlled as it leads to fewer edge-cases. As far as use-cases go, I think there are a number of things to think about: 1. A window that does not want to be maximized. What if the window wants to have a fixed size? Do you simply set it as maximized and let it fail the configure event? In that case the compositor thinks it's maximized but, in reality, it's not. 2. A window that, when you minimize it actually minimizes other windows as well (dialogues for example). This is where Bill's example falls. If you want it more concrete, think about the original multi-window layout of GIMP. I don't want the dialogues visible whenever at least one image window is visible and invisible when none of the image windows are visible. This could probably be handled in a compositor-dictated system, but it will look strange if the image window gets minimized and then, because of lag, the dialogue gets removed a few seconds later. 3. A window that, when you maximize it, responds by maximizing something else. Consider a video player. It may be using a subsurface to display its video and then, when you press the maximize button it actually detaches the video surface and sets it to fullscreen. Again, in a compositor-dominated environment this would really confuse the compositor. Hopefully this is concrete enough to demonstrate my point. On Sun, Mar 17, 2013 at 9:02 PM, Scott Moreau <[email protected]> wrote: >>> I am not really sure what you are talking about but I'm also not sure I have >>> time for it. The fact is that this is only a basic implementation to >>> exercise the new protocol. If you would like to contribute code, the policy >>> is that patches are welcome. A working implementation of what you think is >>> better might also help to illustrate your points better. >> >> That's not really a good answer when we're talking about the core >> protocol. If this is so experimental, it should be added as a weston >> extension, not to the wayland core. Before we start adding things to >> the wayland core protocol, we need to get it right. > > This series provides a complete example implementation in weston. > Maximize and fullscreen are part of wl_shell_interface. It wouldn't > make sense to put it anywhere else, than the same place as these > existing events/requests. Yes, it is an implementation. However, I think there are some corner-cases and things that need to be thought about. Part of my point above is that you can't blow off the people who review your code with "I don't have time" and then expect Kristian to apply your patches. We need to be careful with the core protocol and make sure we get it right. There is a big limit as to how much of the "implement it now and fix it later" we can do with the core protocol. As soon as we have the 1.1 release, we (and the rest of the Linux community) are stuck with it regardless of whether or not it's a good implementation. I hope that's more clear, --Jason Ekstrand _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
