Weston : ideas about xdg_sell, and implementation for a taskbar

[Bill Spitzak]

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

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

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

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 
stays on-screen.

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.

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

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.