Scott et. al, I'm not going to try and answer everything because a lot has happened on this topic and I think we're on the same page on most of the technical details.
>> 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> > >Yes, I completely agree. This is the same semantics of the current >maximize implementation. Ok, I think we're on the same page: The compositor gives the request to the client -> client tells the compositor what windows need changing -> compositor performs changes. As far as frame callbacks go, like pq said, that's pretty much orthogonal. I think we should just let the compositor implementation take care of that. The point here is that none of this should get implemented by the client removing the buffer from the surface in order to unmap it. That's unacceptable. Instead, it should happen in terms of modes. There is one more question that I think needs to be answered. And that is: do we handle things in terms of set/unset or in terms of set_maximized, set_fullscreen, set_minimized, and set_normal (probably want a better name for that one). Really, which of those two we do doesn't matter that much because the toolkit can force it either way. It's mostly a matter of who tracks the state and handles it. I think I like simply setting the state instead of keeping track of set/unset better, but I'm open to discussion on that. Assuming we can get the above question answered, I think I'd like to see a version 2 with the following changes: 1. Clear and precise documentation. If we're going to require a client response to a minimize event, it needs to be well-documented. 2. Events for each of: request_maximize, request_minimize, and request_close (The client should be able to handle fullscreen itself). I do prefer the request_x because it makes it more clear that the compositor is requesting the client to minimize, not simply telling it that it already is. 3. Some way for the client to unset maximized, minimized etc. 4. An enum and a request telling the compositor which of these operations is supported. This way the compositor can hide the buttons or whatever. The client can always ignore the request_x events, but this provides a nicer UI. Thanks, --Jason Ekstrand _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
