<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Bill,<br>Because I want to respond to everything in one e-mail, I'm going to try and address your comments here even though they may not show up.<br></div>
<div class="gmail_quote"><br>On Wed, Oct 30, 2013 at 3:19 PM, Rafael Antognolli <span dir="ltr"><<a href="mailto:antognolli@gmail.com" target="_blank">antognolli@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">
Hi, I'm back to work on this, hopefully this time in a<br>
non-intermittent way. Some comments below:<br>
<div class="im"><br>
On Thu, Oct 24, 2013 at 12:00 AM, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> Jason Ekstrand wrote:<br>
><br>
>> At this point, I think I can propose a solution which should allow for<br>
>> client control while still keeping the compositor in control:<br>
>>  1) The xdg_surface has a pare of activate/deactivate events.  I think we<br>
>> need more than keyboard focus here because the user may not have a physical<br>
>> keyboard.<br>
><br>
><br>
> How does a client request an activation? And can it refuse an activation<br>
> from the compositor? Here is the sequence I see:<br>
><br>
>  - Compositor sends some kind of "I want you to activate" to client<br>
>  - Client (if it wants to activate) sends an "activate" request. Clients<br>
> can also do this in response to mouse/key events without an activate from<br>
> the composiitor.<br>
>  - Compositor sends a "lost activation" to previous active client, and a<br>
> "gained activation" to the new client.<br>
><br>
> As I see it the only reason the compositor will send the first event is due<br>
> to global shortcuts like Alt+Tab or some pager application, and destruction<br>
> of the current active client. If clicks or hovering is going to activate a<br>
> client, it is the client's responsibility to implement it.<br>
<br>
</div>I'm sorry, but I fail to understand how a user could choose between<br>
click to focus, or sloopy focus, if that's up to the client to<br>
implement it. Wouldn't this lead to something like: if I use this<br>
video player A, but it only implements sloopy focus, and I want click<br>
to focus, I have to change to some other video player B?<br>
<br>
Again, sorry for my ignorance, I might have not completely understood<br>
your point.<br></blockquote><div><br></div><div>Yes, in theory they could read the configuration of the compositor.  However, that's even more configuration syncing that we have to do and anything other than the major 3 toolkits (Qt, GTK, and EFL) probably won't bother.  They'll simply implement whatever focus model is easiest (or liked by the developer) and they certainly won't go searching for special globals and looking for config files for every compositor/toolkit.  I really don't want to build this kind of inconsistency into the system and I don't see why it's justified.<br>
<br></div><div>Also, why is a client, out of the blue, trying to take the focus?  The compositor is going to have focus rules to prevent bad clients from doing nasty things anyway.  Why not have the compositor tell the client when it's allowed to have active.  This could be as simple as an activate request with a take_active response.  Concerning semantics, I expect the activate request to be sent whenever an event occurs on a non-active client that the compositor deems activation-worthy.  This could include pointer enter, pointer button, keyboard key, or nothing client-discernible at all (alt-tab).<br>
<br></div><div>I would expect raise to act the same way (but I don't think we're debating that one as much.<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><div class="h5"><br>
> I still feel it is going to be identical to the keyboard focus for some<br>
> seat. A seat can have a focus even if it has no keyboard.<br>
><br>
><br>
>>  2) A request_raise event to which the client *can* respond with any<br>
>> number of raise requests.<br>
><br>
><br>
> Again exactly the same sequence. The compositor can send a "I want you to<br>
> raise" to the client, which it *can* respond to with raises. The client can<br>
> also raise itself in response to events. There probably does not need to be<br>
> feedback to the client whether the raise worked.<br></div></div></blockquote><div><br></div><div>I think we agree here.  The compositor will have its own rules about when the client can actually raise.  However, it should be able to re-order its own windows at any time.<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><div class="h5">
><br>
><br>
>>  3) Both the request_raise and the activate events have a serial.  If the<br>
>> event corresponded to some user input (such as a mouse press) then the<br>
>> serial will match that of the input event.  Otherwise, it will have its own<br>
>> serial.<br>
><br>
><br>
> Yes. The compositor must be able to tell what event caused the client to<br>
> make the request. It can then ignore them, and solve race conditions with<br>
> multiple clients.<br>
><br>
><br>
>> Ok. I think I may be understanding transient windows better now (or maybe<br>
>> have come up with a good definition).  I think it's best seen in comparison<br>
>> to toplevel windows.  A toplevel window is "primary" in the sense that you<br>
>> expect it to have a button in the task bar, want it to show in expose, etc.<br>
>> A transient window, on the other hand, is one that is peripheral such as a<br>
>> dialogue box or the floating toolboxes in GIMP.  You don't want every<br>
>> transient window show up in expose mode or in the task bar.  In fact, you<br>
>> don't want it to show up except in relation to another toplevel window.<br>
>><br>
>> That said, it is a very different concept to subsurfaces.  In particular,<br>
>> the client should not be able to always know where it is nor should it set<br>
>> it's location relative to another window directly. (This is different from<br>
>> popups).<br>
><br>
><br>
> Having written some applications, I absolutely want complete control over<br>
> where transient windows appear!!!! They must appear in correct positions<br>
> relative to the mouse cursor and to not obscure important information in the<br>
> main window. Also it is very useful to make fancy transient tooltips that<br>
> are hovering windows with pointers and that is not going to work if I can't<br>
> make the pointers point at things!<br>
<br>
</div></div>I agree with you here, we have that exactly same use case in EFL. Not<br>
being able to set where the transient surface will be is going to<br>
prevent us to implement that behavior. Unless some other kind of<br>
surface should be used for this purpose.<br></blockquote><div><br></div><div>One thing worth noting here is that the client doesn't know where the window is, so it can't always properly place these transient windows (in the case of toolboxes).  I know, Bill, that you have advocated many times in the past that the compositor give the client the full transformation matrix of the window at all times.  However I don't think this is going to happen.  It wasn't my decision.  Let's not start that argument again here.  If we want to restore window positions (and I would like that eventually), I think we can come up with some way of doing so that doesn't make the compositor slave to the clients.<br>
<br></div><div>Now, concerning other pop-up type things such as tooltips, speech bubbles, arrows, etc.  Perhaps they aren't the same as a standard transient window.  I would want a toolbox to not show up in a task bar (not toplevel) but to also move independent of its parent.  Perhaps there is another category in here.  Maybe we want four types: toplevel, transient (toolboxes etc.), tooltip (position relative to parent), and popup (tooltip + grab semantics).  It would be good to talk to Giulio Camuffo about this as he spent quite some time banging his head on menus in Qt.<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>
> If the client tells the compostor to drag a window (due perhaps to a mouse<br>
> drag started in the window border) it is probably ok that the client does<br>
> not know where the window ends up (though it is really annoying because it<br>
> prevents clients from saving their window layouts).<br>
><br>
> Also I see no reason that the client can't tell the compositor to drag a<br>
> subwindow as well. You are not convincing me that there is any difference,<br>
> the more I look at it the more I am convinced that these concepts MUST be<br>
> merged so that they each don't lack useful abilities the other ones have.<br>
<br>
</div>I *think* that the reason behind it is that they have<br>
specific/specialized usage. Subsurfaces are specially for rendering<br>
things not in the main surface, but still merged in the same "window",<br>
so that the user would not see a difference, and have no way to know<br>
that there's another surface in there.<br></blockquote><div><br></div><div>Yes! In particular, subsurfaces are a compositor-wide thing, where as popup/transient/tooltip is entirely a *shell* thing.  Perhaps in some compositor there is no distinction.  However, just because they look similar in the scenegraph does not mean they are the same.<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">
<br>
Transient and popup surfaces have another semantic meaning, they are<br>
more like real windows.<br></blockquote><div><br></div><div>Yes, they are real windows.  This also tells the compositor that the surface is not actually part of the window.  For instance, it may not want to render menus/tooltips in an expose mode.  However, subsurfaces would have to get rendered in that mode because they are part of the original surface.<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">
<br>
For a subsurface, there's no big reason to grab mouse pointer and so.<br>
On the other hand, it wouldn't make sense to synchronize the commit of<br>
a transient window with the one from a toplevel surface. At least from<br>
our toolkit point of view (EFL) it would make things more complicated<br>
IMHO.<br>
<br>
Of course they could all be merged, but then we would just end up with<br>
a big generic one surface to rule them all. Not sure if this is<br>
intended.<br></blockquote><div><br></div><div>I really don't think we want one surface to rule them all.  There is also a huge component-separation issue here.  I don't want subsurfaces to be 100% a shell thing and I don't want grab symantics built into subsurfaces (or window move symantics for that matter).  If we couple things too closely, it's going to make it impossible to implement anything other than a desktop shell with Wayland.  We DO NOT want that!<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">
<br>
Though that's only my current understanding, which is quite limited<br>
about Wayland so far.<br>
<div class="im"><br>
>> Given this understanding of transient windows, I'm less convinced that we<br>
>> need a window raise tree.<br>
><br>
><br>
> I *think* you are saying "there is no reason for the 'raise tree' to be a<br>
> different tree than the 'parent tree'". This is prehaps why I did not<br>
> understand what you were getting at. I never wanted more than a single tree,<br>
> and I thought Kristian was asking whether there should be *one* or *zero*<br>
> trees. Your email was about whether there should be *two* or *one* tree. I<br>
> want one, the same as you do, I think.<br>
><br>
> So what I propose I think is the same as you are proposing: there is a<br>
> single tree (actually a forest), of parent/child surface relationships. The<br>
> "children" are sometimes called "transient windows", or "popup windows",<br>
> etc. This both communicates what window is the "parent" and makes map and<br>
> raise of the parents atomic with the children.<br>
><br>
> If a client really has a reason to make the parenting different than the<br>
> raising it can temporarily rearrange the tree before doing a raise and then<br>
> put it back.<br></div></blockquote><div><br>I'm pretty sure we agree here.  I see no reason for 2 trees either.  And I do think we want some sort of a tree.  I think it's reasonable to make the toplevel windows roots (no parent) and make all the other little window types (popup, transient, tooltip) take a parent parameter which does not have to be toplevel.  However, I would also like there to be some sort of "commit" operation  so it can be don atomically.  One idea would be to simply make that commit operation the same as the raise.<br>
<br></div><div>Thanks, I hope I addressed everything.<br></div><div>--Jason Ekstrand</div></div><br></div></div>