<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 17, 2013 at 12:32 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/15/2013 10:53 PM, Kristian Høgsberg wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - transient for shouldn't take position.<br> </blockquote> <br></div> What? I think that is necessary. It is relative to the parent surface.<div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - New keyboard focus protocol: instead of active surface meaning<br> "has keyboard focus" we need something that works in a touch-only<br> environment and we need a more generic way to create surfaces that<br> don't take keyboard focus. I propose a new xdg_surface.activate event<br> that indicates that the surface has been activated (by clicking or<br> touching or alt-tabbing to it (or hovering in case of sloppy focus)).<br> When a surface is "the active surface", the client can choose to<br> assign kb focus (xdg_surface.take_keyboard_<u></u>focus) to any of its<br> surfaces.<br> </blockquote> <br></div> 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).<br> <br> 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.<br> <br> 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. </blockquote> <div><br></div><div>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.<br> <br>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).<br> <br></div><div>Most window managers I've seen have three basic window focus models:<br></div><div> 1. Click to focus<br></div><div> 2. Focus follows mouse, click to raise<br></div><div> 3. Focus follows mouse, click or hold mouse above window for a short time to raise.<br> <br></div><div>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.<br> <br></div><div>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.<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - We need to solve stacking - how does a wayland shell raise an<br> applications and all its surfaces correctly. The two ideas I have are<br> either 1) let the client raise its surfaces when it's active (uses the<br> same xdg_surface.activate event as above) and just let the client<br> control which surfaces to raise and in which order in response to<br> being activated or 2) let the client describe above/below relation<br> between its surfaces and make sure the shell respects these<br> constraints when raising a surface (eg, toolbars above documents, but<br> no relation between individual toolbar surfaces or doc surfaces.<br> Raising a document raises all the toolbox surfaces to be on top, but<br> doesn't affect other documents and preserves the stacking order of the<br> toolbox surface).<br> </blockquote> <br></div> 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.<br> <br> 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.<br> <br> The reasons for supporting the tree (rather than have the client do everything) are:<br> <br> 1. Pagers and task switchers can use this tree to determine that a bunch of surfaces are related<br> <br> 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.<br> <br> 3. Familiarity and resemblence to other window systems.<br></blockquote><div><br></div><div>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.<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br> </blockquote><div><br></div><div>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)<br> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br> <br> 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.<div class="HOEnZb"> <div class="h5"><br></div></div></blockquote><div><br></div><div>Just a few quick thoughs. I'm sure I'll have more as the discussion goes on.<br></div><div>--Jason Ekstrand <br></div></div><br></div></div>