Weston : ideas about xdg_sell, and implementation for a taskbar
spitzak at gmail.com
Tue Feb 11 12:26:30 PST 2014
sardemff7+wayland at sardemff7.net 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
> 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
> 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.
More information about the wayland-devel