<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 3:36 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">Jason Ekstrand wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>

</blockquote>
<br></div>
I also use sloppy focus all the time, which is why I *want* my proposal. I see it as the opposite: I am allowing a client to be sloppy focus whether or not the compositor thinks it should be.<br>
<br>
Also for any focus model, my primary concern is that I want to allow the areas that cause the focus to change to not have to correspond to the edges of surfaces. In sloppy-focus it could help a lot if you had to point at the text box, rather than the toolbar or border or a control panel, to get the focus.</blockquote>
<div><br>I see what you mean here.  However, I think apps doing this will cause 
more trouble than it's worth.  One thing about current sloppy focus 
implementations is that you can click anywhere in the window to raise 
it.  You want to change this.  However, what happens if that window is 
partially obscured.  In your scheme, you would have to move the window 
so that the magic text box is uncovered in order to raise it.  As is, if
 I want to see said text box, I click the window to raise it so I can 
get to the text box.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>

</blockquote>
<br></div>
Yes I agree mostly. Absolutely "active" and "raised" must be independent. However I now do not think there needs to be any difference between "active" and the keyboard focus for a particular seat.<br>

<br>
The compositor must NEVER NEVER NEVER either raise or activate a surface. It can only send request events to the client. The client can then produce actual raise and activate actions. The only thing a compositor can do is ignore these if it thinks they are inappropriate.</blockquote>
<div><br></div><div>I 100% agree with you here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Most window managers I've seen have three basic window focus models:<br>
 1. Click to focus<br>
</blockquote>
<br></div>
My proposal would allow the focus to change depending on what the user clicks on.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 2. Focus follows mouse, click to raise<br>
</blockquote>
<br></div>
My proposal (and I think everybody's proposal) would allow the client to decide if a click raised the window. In particular it would allow you to hit buttons and select text without raising the window, but clicking to move the insertion point or draw would raise it.</blockquote>
<div> <br></div><div>Yes, I agree it would be nice if you could select text without raising the window.  However, I'd still like a way to raise it without having to click a particular region.  That's an interesting UI problem<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 3. Focus follows mouse, click or hold mouse above window for a short time to raise.<br>
</blockquote>
<br></div>
I think again this could be client responsibility. Though I would have a "hover event" sent from the compositor, so that the timeout can agree between all clients.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>

</blockquote>
<br></div>
To do sloppy focus, the client would respond to a mouse-enter event by requesting activation/focus. I'm not sure why you don't think sloppy focus works under what I propose.<br>
<br>
Activation would *NOT* raise the surface, unless the client wants it to.<div class="im"><br></div></blockquote><div><br></div><div>I think the issue here is that the compositor must allow an application to raise.  It must not raise unless instructed that it can by the compositor.  There also needs to be a consistent way for applications to know whether or not they are allowed to raise.  If the only rule is "you have to be active to raise" then a client can "take active" as soon as they see mouse movement and then raise immediately afterwards.<br>
<br></div><div>Perhaps we could allow for some more flexibility if there was a way for the client to reject an activation.  However, I still have the above fears.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>

</blockquote>
<br></div>
This is the first proposal I said, echoing Kristian's first proposal. Basically the client is entirely in control. There really does not need to be any tree, just an atomic sequence of raises with a commit. I think this should always work in Wayland.<br>

<br>
The "tree" I propose is so that pager clients can have a clear idea what the relationship between surfaces are. The problem with current trees such as in ICCCM is that they end up really really complex, because in fact what is wanted is a directed acyclic graph (more than one parent per surface, this is attempted with "window groups" in ICCCM). I propose this be avoided by:<br>

<br>
The client can always change the tree whether or not the surfaces are mapped. Changing the tree has no visible effect even if the current stacking is "wrong". Surfaces are only raised by requests from the client, so the client can always rearrange the tree before raising.<br>

<br></blockquote><div><br></div><div>Yes, I like this.  I don't think it's feasible to try and keep some crazy DAG.  As long as a client can atomically raise a bunch of windows we should be ok.  A tree, whether or not it persists after the raise, will accomplish this.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
    I believe these child surfaces and "subsurfaces" are EXACTLY the<br>
    same thing.<br>
<br></div><div class="im">
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></blockquote>
<br>
That's what I'm complaining about. Wayland currently has two implementations of a lot of stuff, depending on whether it is a floating  window or subsurface, even though these look and act IDENTICAL unless you manage to get another surface from another client in-between the floating window and it's parent. That is bad design. And there is no reason subsurfaces are denied the "extra pointer symantics", and no reason floating windows are denied all the sync work done for multi-client subsurfaces.<br>

<br>
I am using the word "transient" to mean a surface that stays above it's parent, but otherwise has no effect.<br>
<br>
"popup" seems to mean an atomic mapping of the window and pointer grab, and possibly automatic unmapping when clicked outside? I think Wayland is being excessively complex. I think somehow doing the grab before the map would work to make them atomic. Instead of unmapping, I would have a press outside the grabbing surface followed by a release cancel the grab, but only after reporting the events as normal to the grabbing surface. And the "popup" is unmapped by the client, not because it lost the grab. In any case there really should be no difference between transients, popups, and clients grabbing the pointer.<br>

<br>
And it would be really nice if all this worked for subsurfaces.<br></blockquote><div><br></div><div>I still don't think these *should* be the same.  I understand that the semantics are similar, particularly for popup windows.  That said, Kristian has talked about removing the coordinates from "transient".  If we remove the coordinates, then I'm not sure we even need "transient" as clients can simply ensure that that window always gets raised with the parent.  Allowing clients to be in complete control of window stacking order (within the client) would make a lot of things simpler.<br>
<br></div><div>Part of this is that I'm still not 100% happy with the fact that subsurfaces don't get clipped to their parent.  (However, my feelings on subsurface design are off topic here).  That said, If it were to change, it would cause problems with using it for popups and things of the like.  Also, this would require all compositors supporting the xdg_shell to support subsurfaces in order to have a useful shell.  Right now, subsurfaces are optional..<br>
</div></div><br></div></div>