<div dir="ltr">On Tue, Oct 22, 2013 at 10:46 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/22/2013 05:59 PM, Jason Ekstrand wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see what you mean here.  However, I think apps doing this will cause<br>
more trouble than it's worth.  One thing about current sloppy focus<br>
implementations is that you can click anywhere in the window to raise<br>
it.  You want to change this.  However, what happens if that window is<br>
partially obscured.  In your scheme, you would have to move the window<br>
so that the magic text box is uncovered in order to raise it.  As is, if<br>
I want to see said text box, I click the window to raise it so I can get<br>
to the text box.<br>
</blockquote>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, I agree it would be nice if you could select text without raising<br>
the window.  However, I'd still like a way to raise it without having to<br>
click a particular region.  That's an interesting UI problem<br>
</blockquote>
<br></div>
I think the clients can raise if the user clicks on a "dead" area where the click serves no purpose. The most obvious is the window borders, but also gaps between widgets and widgets that don't use click for anything could raise the window.<br>

<br>
It would still be possible for all the visible area of a surface to be covered with buttons so there is nowhere to click to raise it. If this is really a problem then perhaps the user holds down some shift key and clicks?<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps we could allow for some more flexibility if there was a way for<br>
the client to reject an activation.  However, I still have the above fears.<br>
</blockquote>
<br></div>
Absolutely a client must be able to "reject an activation". This would be just like raise and focus: the compositor can only send a request event to the client. The client must respond with an activate request if it really wants activation.<br>

<br>
However I think this may mean there is no difference between activation and having a particular seat's keyboard focus.<div class="im"><br></div></blockquote><div><br></div><div style>At this point, I think I can propose a solution which should allow for client control while still keeping the compositor in control:</div>
<div style> 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.</div><div style> 2) A request_raise event to which the client *can* respond with any number of raise requests.</div>
<div style> 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.</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">
Yes, I like this.  I don't think it's feasible to try and keep some<br>
crazy DAG.  As long as a client can atomically raise a bunch of windows<br>
we should be ok.  A tree, whether or not it persists after the raise,<br>
will accomplish this.<br>
</blockquote>
<br></div>
I think if the tree does not persist then it is identical to the "client does a lot of raises atomically" version. This is however a possible solution.<br>
<br>
The only reason for the tree is so that other clients can examine it and get some ideas about the relationship between surfaces. And also for familiarity with other window systems. I think it may also be useful for RDP to other window systems which may not have atomic sets of raises.<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
             I believe these child surfaces and "subsurfaces" are<br>
        EXACTLY the<br>
             same thing.<br></div><div class="im">
I still don't think these *should* be the same.  I understand that the<br>
semantics are similar, particularly for popup windows.  That said,<br>
Kristian has talked about removing the coordinates from "transient".<br>
</div></blockquote>
<br>
Not clear what he is getting at there. If the client can't position a popup menu in the correct location it is pretty useless. I suspect he is using a different definition of "transient" than I am.<div class="im">
<br></div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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).</div>
<div style><br></div><div style>Given this understanding of transient windows, I'm less convinced that we need a window raise tree.  I don't see a reason why the client would want to raise more than one toplevel window at any given time.  It should be able to just re-parent the needed transient windows and raise the toplevel one.  (or, for that matter, just raise a transient window).  The only issue here is that it needs a way to "commit" the tree so that it can re-arrange things atomically.  If we simply make re-parenting of transient windows not apply until a raise, we can get atomic.</div>
<div style><br></div></div></div></div>