Weston : ideas about xdg_sell, and implementation for a taskbar
spitzak at gmail.com
Mon Feb 10 17:23:00 PST 2014
sardemff7+wayland at sardemff7.net wrote:
>> 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.
May not have explained it correctly. It sounded like you were not going
to allow dialogs to be minimized except as a side-effect of minimizing
the parent. I certainly want to allow this! And I certainly want to
support minimizing multiple surfaces.
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.
>>> 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
> 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.
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.
>>> 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.
I assume you mean "minimize", not "unfocus"? It must be possible to
minimize windows that don't have focus.
It sounds like you are describing the 3-way communication I proposed. I
see 3 steps:
1. Client decides it wants to minimize, tells compositor (this step is
not done if the compositor chooses to do so).
2. Compositor tells client that the minimize is happening.
3. (the step you are missing) client tells compositor it has corrected
all it's surfaces to reflect the result of minimizing and it is ok to
>> 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.
Again not sure why you said "unfocus", but I believe you are describing
my 3-step version.
>> 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
That is *EXACTLY* what I want to support, although it may be a little
more sensible to imagine it writing it in a *different* window that
My primary goal is to allow the client to change the parent/child
relationships. This is to avoid having to communicate a directed acyclic
graph from the client to compositor of window relationships, which is
really messy and is still making assumptions about how the ui should
work. In fact I did not think about drawing until you mentioned
redrawing things inactive, which is why I thought it was acceptable for
the compositor to ignore minimize without the client knowing.
> The surfaces relation are already taken care of from point 1 here, no
> harm in actually hide everything.
No, not if the relationships are more complex than the compositor can
handle. Rather than make the compositor handle all possible window
relationships I would like this to remain in the client, where it is a
lot easier to develop and test new ideas.
> 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).
Yes I agree
> 2. On .request_set_minimized, the client is free to reparent other
> surfaces to keep its UI in a consistent state.
This MUST be done before any visible change happens on-screen, so that
these changes are atomic with the minimized window disappearing.
Therefore there must be some kind of "commit" for the client to tell the
compositor to finish the minimize.
> 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.
The communication can't be just unfocus because it is possible to
minimize and un-minimize unfocused windows.
> 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).
Not sure what you meant by that. I'm pretty certain that once the app is
minimized it will work exactly the way you are saying with previews.
More information about the wayland-devel