On Fri, Mar 8, 2013 at 4:39 PM, Scott Moreau <ore...@gmail.com> wrote: > > > On Fri, Mar 8, 2013 at 3:28 PM, Bill Spitzak <spit...@gmail.com> wrote: >> >> Scott Moreau wrote: >> >>> "Further, the term minimize is relatively subjective and defined by the >>> implementation. Clients should not expect that minimized means the >>> surface >>> will be invisable to the user. There are several use cases where >>> displaying >>> minimized surfaces will be useful." >>> >>> Minimize can be handled differently by each compositor. The protocol does >>> not define minimize explicitly. The important part is that the protocol is >>> in place so that the compositor and clients can communicate minimize state >>> information, not unlike maximize. The comment you're looking at does not >>> represent any protocol restriction, it's merely a reminder that suggests a >>> minimize surface might not be unmapped. We might want to view 'live' >>> minimized surfaces in a window preview, graphical window switcher or scaling >>> feature. It seems that you're misinterpreting this specific text but I'm not >>> really sure what you mean. Just know that the weston implementation is a >>> reference with working proof-of-concepts, exercising and demonstrating the >>> protocol. A different wayland compositor can handle all of these events and >>> requests differently. >> >> >> Actually perhaps I am misunderstanding it. Does it just send an "unmap >> request" from the shell to the client? From the code it seems to cause the >> compositor to stop showing the minimized window without any indication being >> sent to the client at all, which I absolutely disagree with! >> >> If in fact the window will not vanish until the client responds to the >> unmap request, that will allow the client to atomically unmap child windows >> if wanted. >> >> I'm not sure if that is a good idea to have the "unmap request" without an >> indication that it is due to a minimize, though. Maybe there are multiple >> reasons for an unmap request and clients may want to respond differently to >> them. > > > > 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. Also, I think I have to agree with Bill that this is a bit simplistic. The clients should have control over how things get minimized. Also, we probably don't want to simply unmap the surface. As I understand, unmapping is currently done by removing the buffer from the surface. Many desktop environments have a window preview in the switcher or somewhere else. If you want to be able to preview minimized windows, it needs to remain mapped. I guess I don't necessarily have a problem with the events/requests specified, simply that I think thinks need to be clarified and thought out more. For example, does the compositor send a minimize event to the client and expect it to minimize windows or does it simply minimize it? I don't think we want the compositor hiding client windows without letting the client override it. I can provide more thoughts later, but there's my initial thoughts. --Jason Ekstrand _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel