[email protected] wrote:
I was suggesting that one method of minimizing multiple surfaces
would be for the client to arrange them all as children of one of
them and then minimize the parent. The primary purpose is so the
compositor/taskbar knows all those windows are "related", for
instance to produce on a single taskbar entry.
All scenarii are supported. You can reparent or simply minimize everyone.
I was thinking the compositor would need the parent information. For
instance if may show one taskbar entry per minimize request. But there
may be other methods of doing this.
No, because if the client wants to redraw or raise or show or hide
any other surface as a side-effect of the minimize, these changes
will not be atomic with the minimize, resulting in unwanted
flickering of an intermediate display. There has to be a way for the
minimized window to not disappear until the client does some kind of
commit.
The commit *is* the .set_minimized. You can raise, draw everything you
want *then* send the .set_minimized request. It is the last step of the
minimization process. In the scenario of multiple .set_minimized
requests, the last one must be the “main” one (either the one requested
by the compositor or the one triggered by client UI).
Okay this is an interesting method for making atomic minimization
without having to send a parent tree to the compositor.
My main concern is that I think the parent tree is going to be needed
anyway so I'm not sure this adds anything.
Also I am unsure how a client indicates which minimize is the "main"
one, as the compositor can't tell if another minimize is coming. This is
a problem even for compositor-generated minimizes as the client may want
to respond to a minimize request in a dialog box by minimizing the
entire application, not just the dialog box.
I mean “unfocus”. There is no reason to treat the minimized with a
special event. The client already reparented surfaces and raised
everything relevant.
As long as the client is in charge of mimimizing itself (which it now
sounds like you are proposing and is exactly what I was trying to
propose originally) then this is ok.
In fact the client could even assume that it loses the focus so no
unfocus event is needed (but it appears a Wayland design criteria is to
ensure pairing of events so it should be sent, though IMHO this enforced
pairing is a waste of time as no sane client will rely on it).
A surface without focus can be minimized, it's just that the client will
be unable to tell if it worked.
It is true that a client may display incorrect graphics if the
set_minimized is ignored. If it expects an unfocus it could detect this
after a delay but even then the drawing will blink. But I don't think
this is a major concern.
No, I am describing a .request_set_minimized/.set_minimized use case:
1a. The compositor send the .request_set_minimized event.
1b. The client “minimize” button is pressed.
2. The client reparent, draw, raise, do whatever it needs to keep the UI
consistent.
3. The client send the .set_minimized request.
4. The relevant surfaces are hidden by the compositor.
In case 1b with a compositor not supporting minimization, the client
will just looks a bit weird. But:
1. I believe that a user will not expect anything better when using such
a compositor.
2. Using flags in the configure event to inform the client which actions
are supported will just remove such a weird case.
Okay, that sounds exactly like what I proposed, which is the client is
in final control over the minimization. Nothing happens until the client
sends the set_minimized request. I definately prefer this but I must
have misread your description as it sure sounded like you wanted
communication after the compositor minimized the window, not before.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
