Weston : ideas about xdg_sell, and implementation for a taskbar

[sardemff7+wayland at sardemff7.net]

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


> 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