Weston : ideas about xdg_sell, and implementation for a taskbar

sardemff7+wayland at sardemff7.net sardemff7+wayland at sardemff7.net
Mon Feb 10 15:06:56 PST 2014

(Some parts are reordered to makes more sense in my answers. Agreed
parts are removed.)

On 10/02/2014 23:42, Bill Spitzak wrote:
> sardemff7+wayland at sardemff7.net 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.

> 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.

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).



Quentin “Sardem FF7” Glidic

More information about the wayland-devel mailing list