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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
