[email protected] 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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
