Jason Ekstrand wrote:
At this point, I think I can propose a solution which should allow for
client control while still keeping the compositor in control:
1) The xdg_surface has a pare of activate/deactivate events. I think
we need more than keyboard focus here because the user may not have a
physical keyboard.
How does a client request an activation? And can it refuse an activation
from the compositor? Here is the sequence I see:
- Compositor sends some kind of "I want you to activate" to client
- Client (if it wants to activate) sends an "activate" request. Clients
can also do this in response to mouse/key events without an activate
from the composiitor.
- Compositor sends a "lost activation" to previous active client, and a
"gained activation" to the new client.
As I see it the only reason the compositor will send the first event is
due to global shortcuts like Alt+Tab or some pager application, and
destruction of the current active client. If clicks or hovering is going
to activate a client, it is the client's responsibility to implement it.
I still feel it is going to be identical to the keyboard focus for some
seat. A seat can have a focus even if it has no keyboard.
2) A request_raise event to which the client *can* respond with any
number of raise requests.
Again exactly the same sequence. The compositor can send a "I want you
to raise" to the client, which it *can* respond to with raises. The
client can also raise itself in response to events. There probably does
not need to be feedback to the client whether the raise worked.
3) Both the request_raise and the activate events have a serial. If
the event corresponded to some user input (such as a mouse press) then
the serial will match that of the input event. Otherwise, it will have
its own serial.
Yes. The compositor must be able to tell what event caused the client to
make the request. It can then ignore them, and solve race conditions
with multiple clients.
Ok. I think I may be understanding transient windows better now (or
maybe have come up with a good definition). I think it's best seen in
comparison to toplevel windows. A toplevel window is "primary" in the
sense that you expect it to have a button in the task bar, want it to
show in expose, etc. A transient window, on the other hand, is one that
is peripheral such as a dialogue box or the floating toolboxes in GIMP.
You don't want every transient window show up in expose mode or in the
task bar. In fact, you don't want it to show up except in relation to
another toplevel window.
That said, it is a very different concept to subsurfaces. In
particular, the client should not be able to always know where it is nor
should it set it's location relative to another window directly. (This
is different from popups).
Having written some applications, I absolutely want complete control
over where transient windows appear!!!! They must appear in correct
positions relative to the mouse cursor and to not obscure important
information in the main window. Also it is very useful to make fancy
transient tooltips that are hovering windows with pointers and that is
not going to work if I can't make the pointers point at things!
If the client tells the compostor to drag a window (due perhaps to a
mouse drag started in the window border) it is probably ok that the
client does not know where the window ends up (though it is really
annoying because it prevents clients from saving their window layouts).
Also I see no reason that the client can't tell the compositor to drag a
subwindow as well. You are not convincing me that there is any
difference, the more I look at it the more I am convinced that these
concepts MUST be merged so that they each don't lack useful abilities
the other ones have.
Given this understanding of transient windows, I'm less convinced that
we need a window raise tree.
I *think* you are saying "there is no reason for the 'raise tree' to be
a different tree than the 'parent tree'". This is prehaps why I did not
understand what you were getting at. I never wanted more than a single
tree, and I thought Kristian was asking whether there should be *one* or
*zero* trees. Your email was about whether there should be *two* or
*one* tree. I want one, the same as you do, I think.
So what I propose I think is the same as you are proposing: there is a
single tree (actually a forest), of parent/child surface relationships.
The "children" are sometimes called "transient windows", or "popup
windows", etc. This both communicates what window is the "parent" and
makes map and raise of the parents atomic with the children.
If a client really has a reason to make the parenting different than the
raising it can temporarily rearrange the tree before doing a raise and
then put it back.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
