sardemff7+wayl...@sardemff7.net wrote:
First, a compositor may have no mechanism of “minimization”, so it must
not be forced to obey such a request with no meaning for it.
I agree the compositor does not have to obey the minimize request. I
think I am not explaining things clearly: *BOTH* the client and
compositor must decide to minimize or it does not work.
You may be right that the client needs to know it won't work.
Based on Bill’s events and requests, here is what I think should handle
all cases the right way while keeping the global policy on the
compositor’s side [in square brackets, the part(s) that the point ensure]:
1. States that the client *must* call .set_minimized at least on the
same surface as the .request_set_minimized [compositor policy, client
surfaces relations]
Yes I think that is a way to detect dead clients.
Rather than send minimize on many surfaces I propose the client arranges
all the windows it wants to vanish as children of each other and then
sends the minimize request to the top one (the one that the compositor
requested must either be this top one or in the list).
Multiple minimizes can then mean that the client wants multiple taskbar
entries or that unminimizing one window is different than the other.
2. Do not assume anything (e.g. do not draw “inactive” window borders)
before the real events (frame callback, focus events and friends)
[compositor relevant features]
This will not work. The actual vanishing of the minimized window must be
deferred until *after* the client has done this, or it will not be atomic.
3. Only ever use “toplevel” (= no parent) surfaces compositor-side for
the .request_set_minimized [client surfaces relations]
Not sure why you want to limit it like this. I certainly would like the
ability to minimized dialog windows.
4. Have a way for the client to know which features are supported
[client UI consistence]
You may be right that the client does need to know if the compositor
would obey the minimize. I thought it was not a problem but as you point
out the client may redraw the activation or move things around on the
assumption that it is going to work.
My first thought is to make this a 3-way communication. If you hit a
minimize button the client sends a minimize-request-command to the
compositor. The compositor then responds with a minimize-request-event.
The client then knows it is going to work, adjusts all it's display, and
sends a minimize-command.
It may be better to just have an event that says whether the compositor
will obey things, like you suggest.
ALTERNATIVE:
Actually after I typed this I think there may be a scheme that works
more like you want but I'm not sure if it is practical:
1. Client sends a minimize-request on a surface, or the compositor just
decides to minimize a surface.
2. Compositor sends a minimize-notify (or not if it does not want to
minimize). However (here is the tricky part) the surface has not really
minimized! It is still visible on-screen and everything works as before
until the compositor sees a commit that it knows is in response to the
minimize-notify.
3. Client then can respond to the minimize-notify by rearranging the
surface tree, redrawing surfaces, doing minimize-request on other
surfaces, etc. It then eventually does a commit, and the serial number
can be used to identify that it is in response to the minimize-notify
(is this possible in wayland?). Note the client is unable to stop the
surface from minimizing, but can get ready for it.
4. If the client is dead then the compositor just does the minimize
using the current surface parent/child tree.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
