(Some parts are reordered to makes more sense in my answers. Agreed
parts are removed.)
On 10/02/2014 23:42, Bill Spitzak wrote:
[email protected] wrote:
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.
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.
If you want a dialog window to be minimized, then it makes even more
sense to allow minimizing multiple surfaces. The client could want to
minimize everything if you minimize the toolbox.
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.
This will work perfectly. As you said, the window vanished, which means
an “unfocus” event and no more frame callback. The compositor can safely
hide a window even if the decorations were not updated accordingly.
Also, minimizing should not be treated specifically, we already have the
frame callback and focus events.
4. Have a way for the client to know which features are supported
[client UI consistence]
From my previous point, the client UI consistence is assured without
such a mechanism since the client will see no “unfocus” event.
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.
Just use the well-defined “unfocus” event and the minimize request.
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.
There is just no point for the surface to still be visible. Unless some
weird client wants to draw “Oh my god I am minimizing, bye!” in its surface.
The surfaces relation are already taken care of from point 1 here, no
harm in actually hide everything.
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.
As I said, it /should/ be irrelevant.
Summary:
1. .request_set_minimized (from the compositor) on a surface *must be
obeyed* by the client, at least on said surface (e.g. a toolbox can
minimize everything).
2. On .request_set_minimized, the client is free to reparent other
surfaces to keep its UI in a consistent state.
3. The client just handle the “focus/unfocus” event and frame callback
to draw its UI. Minimizing is not a special case as it does not need to be.
It should work in all cases, especially the thumbnails preview: the
surface is drawn inactive but updated as soon as the preview is visible
(while hovering the taskbar item associated to the surface).
Thanks,
--
Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
