[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Jason Ekstrand]

On Thu, Oct 17, 2013 at 12:32 PM, Bill Spitzak <spitzak at gmail.com> wrote:

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


I think I would disagree on this one.  As an avid sloppy-focus user, I
really don't want apps arbitrarily deciding that they are click-to-focus.
While some things (look and feel) are entirely cosmetic, if how apps get
focus is app-dependent, it will drive users crazy.  I think the bigger
issue here is to allow for different modes of focus.

I think the big thing here is that we need to allow for a distinction
between "active" and "raised" and the compositor should be in rough control
of both.  I say rough because the client may want to raise additional
windows (such as toolbars) and it is impossible for the compositor to know
exactly what the client will want to raise.  Therefore, I'm a big fan of
the compositor sending a request_raise event and the client responding with
a series of raise requests (similar to the method recommended for handling
window states).

Most window managers I've seen have three basic window focus models:
 1. Click to focus
 2. Focus follows mouse, click to raise
 3. Focus follows mouse, click or hold mouse above window for a short time
to raise.

I think all of these are valuable and probably not going away.  In
particular, the last one has some accessibility benefits.  Whatever
protocol we come up with, we need to be able to handle all three.  This
means that we need to be able to tell a window that it is active without
raising it.

Bill, Allow me to more directly respond to the suggestion for take_active
that you described above.  The problem isn't so much a configuration
issue.  More to the point, in order to support all three of the above
modes, we have to allow a client to get keyboard focus and raise to the top
without clicking.  If things are handled in terms of take_active then
clients will be able to raise themselves if the user so much as brushes the
mouse across them.  I don't think we should allow clients to do whatever
they want as soon as they get a mouse.  There may be a way to solve this,
but it's not presenting itself immediately.


>
>       - 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 would agree that some sort of a tree is probably a good idea if for no
other reason than it makes raising atomic.  One idea would be to treat a
xdg_surface.raise request like a sort of commit.  The client would make a
bunch of xdg_surface.place_above (or some other name) requests to build the
tree and then call xdg_surface.raise on the root of the tree to raise the
whole tree.  After that we could probably discard the place_above
relationships and let the client rebuild them for the next raise.  Not that
that's really necessary but, as long as we allow clients to modify stacking
at times other than a full activate/raise, I don't see how useful keeping
the tree would be all that useful.


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

The problem here is that subsurfaces are a compositor-wide thing while
transient and popup are shell things.  Popup involves extra pointer
symantics. (I still don't fully understand transient)


> 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.
>
>
Just a few quick thoughs.  I'm sure I'll have more as the discussion goes
on.
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131021/e9ab43bf/attachment.html>