On 10/15/2013 10:53 PM, Kristian Høgsberg wrote:
- transient for shouldn't take position.
What? I think that is necessary. It is relative to the parent surface.
- New keyboard focus protocol: instead of active surface meaning
"has keyboard focus" we need something that works in a touch-only
environment and we need a more generic way to create surfaces that
don't take keyboard focus. I propose a new xdg_surface.activate event
that indicates that the surface has been activated (by clicking or
touching or alt-tabbing to it (or hovering in case of sloppy focus)).
When a surface is "the active surface", the client can choose to
assign kb focus (xdg_surface.take_keyboard_focus) to any of its
surfaces.
Please allow clients to take the active themselves, maybe with a
xdg_surface.take_active request, and clients can decide themselves
whether a click or hover activates them. The compositor should not
activate surfaces due to events done to the surface (it can still
activate them due to things like alt+tab shortcuts and due to the
current active surface being unmapped).
This will allow clients to decide not to activate themselves, to make
the rules vary depending on where the events happen, and so that
point-to-type is a per-client rule, not a global one.
Hostile clients will not be able to grab the active, as the active
request will contain an event id that triggered it, and the compositor
can ignore it if the event is not a keystroke or mouse event to that client.
- We need to solve stacking - how does a wayland shell raise an
applications and all its surfaces correctly. The two ideas I have are
either 1) let the client raise its surfaces when it's active (uses the
same xdg_surface.activate event as above) and just let the client
control which surfaces to raise and in which order in response to
being activated or 2) let the client describe above/below relation
between its surfaces and make sure the shell respects these
constraints when raising a surface (eg, toolbars above documents, but
no relation between individual toolbar surfaces or doc surfaces.
Raising a document raises all the toolbox surfaces to be on top, but
doesn't affect other documents and preserves the stacking order of the
toolbox surface).
I am in favor of a hybrid approach. Version 1 above should always work:
a client can make a bunch of surfaces, not communicate any relationship
information about them to the compositor, and always have complete
knowledge and control over what order they are composited in. It can
insure that top-to-bottom order of 3 surfaces is A,B,C by raising B and
then raising A. And the compositor must *NEVER* raise surfaces itself.
Surfaces are ONLY raised in response to a request from the client. This
means the client always knows exactly what order they are in.
However the compositor should also support a tree of parent
relationships between surfaces, which a client may choose to use. Each
surface has a "parent", which is either null or another surface. If
surface A has a parent of B, a raise of B will also raise A, and a
map/unmap of B will map/unmap A. A client can at any moment change the
parent of any surface to any other one except it can't make a loop,
changing the tree will not change the state or position of any surface
even if it is "wrong", the tree only controls what happens when requests
are made to parents.
The reasons for supporting the tree (rather than have the client do
everything) are:
1. Pagers and task switchers can use this tree to determine that a bunch
of surfaces are related
2. Compositors may be able to take advantage of knowledge that two
surfaces are 'stuck together' and will raise as a unit. In particular it
can take advantage of everything being done for subsurfaces.
3. Familiarity and resemblence to other window systems.
I believe these child surfaces and "subsurfaces" are EXACTLY the same
thing. The only difference is that raising a subsurface puts it just
above the top-most subsurface with the same parent, while raising a
non-subsurface puts it at the top of it's layer, above surfaces
belonging to other clients. Merging sub, transient, and popup surfaces
will simplify wayland and provide advantages to both that currently only
exist for one or the other.
Because nothing happens unless raise or map requests are made from the
client, the client is still in control. It can change the tree any way
it wants before doing a raise request.
The common example of a floating dialog over two main windows would be
accomplished by the client changing the parent of the dialog to the main
window it is raising. This ability to change the tree avoids the need to
send a directed acyclic graph to the compositor, vastly simplifying the
compositor api.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
