<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan <<a href="mailto:gregory.merchan@gmail.com" target="_blank">gregory.merchan@gmail.com</a>> wrote: <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">On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote: >> >> Jason Ekstrand wrote: >> >>> Yes, in theory they could read the configuration of the compositor. >> >> >>> I really don't want to build this kind of inconsistency into the system >>> and I don't see why it's justified. >> >> >> I think I see what you are getting at. I think a scheme that allows simple >> applications to obey the global setting without thinking, but still allows >> applications that have a good reason to do tricks with the focus, and also >> matches the raise proposal, is this: >> >> - The compositor sends an "I want you to activate" event, as you propose. >> - The client can respond to this with an "activate" request. Or it could >> send an "activate" request at other times if it wants. >> - The compositor responds to the "activate" request by either ignoring it >> or actually doing the activation. >> - The compositor sends an "activated" event that the client can respond to >> by redrawing to show the fact that they are activated. >> >> If a client just echoes the "I want you to activate" event then it will >> work as you expect. A client could also wait after the event until the mouse >> enters a correct location or clicks on the right thing. It could also try to >> generate spurious activates but the compositor may ignore them. >> > > I still don't understand why a client would want to not activate. 狢 can see > not wanting to raise, but why not activate? </div>As Bill mentioned in a follow-up, drag sources would want to not activate. This can be handled more simply than described above, without a special "activate" system. I assume "activation" applies to a window, not a client. First, clients are responsible for requesting activation when it is appropriate. Second, the compositor always activates when it is appropriate. The complicated part is determining what is appropriate. There are 5 activation policies. For each policy, the compositor activates windows as needed for key traversal (e.g. Alt+Tab), task bar actions, when an active window goes away, viewport changes, etc. The compositor also activates windows when a request for activation has the correct signature. The policies are distinguished by special cases for activation or deactivation: 1. PointerRoot: Activates a window when the pointer enters it and deactivates it when the pointer leaves. 2. Sloppy: Activates a window when the pointer enters it. 3. Delayed sloppy: Activates a window when the pointer has been within for a short time. 4. Click-to-focus: Activates a window when it is clicked. 5. Windows/MacOS-style: Does not activate a window, except as it does for all policies. (I suppose a "Delayed PointerRoot" policy is possible, but I've never seen any discussion of it.) For each of these policies, another distinction may be made according to signature required to honor an activation request. The strictest form is to deny all requests, which is not possible on X11 because there is no redirection for focus changes. An often desired form for the correct signature, among X11 users, is that the request must come from a client which is already activated. For example, this allows an active program to activate a dialog, but prevents other programs from activating any windows. Unless I am mistaken, most attempts at "focus stealing prevention" have aimed at such a policy. I'm pretty sure I've seen at least one window manager that will fight with bad programs to enforce such a policy. On X11, the correct signature is always only that the timestamp is later than the last focus change timestamp, and this may be achieved by using CURRENT_TIME. Convention is relied upon to avoid chaos, that convention is that clients must always use a valid timestamp to set focus, and there are 4 sources of valid timestamps: 1) button events, 2) key events, 3) property change events, and 4) a window manager message. This last source exists to address the lack of a timestamp in the focus change event of the X protocol. I will refer to this as the "valid event" signature. Wayland is a different system and there are more options for the signature requirement. If I understand the protocol correctly, the serial field of pointer, keyboard, and touch events could be used as a signature. (Like X, wl_keyboard::enter does not have a time argument, so that is not an option.) The strictest form of these policies--denying all requests--can be achieved because the compositor is in control; it's like a window manager and an X server combined in that sense. The "must be active" signature can be implemented by checking that the serial number came from an event sent to an active client. The valid event signature can be implemented by checking that the serial number came from a wl_pointer::button event, a wl_keyboard::key event, a wl_keyboard::enter event, or wl_touch::down event. The compositor is always in control, so clients can request activation as much as they like without messing things up. Clients cannot prevent the compositor from implementing any of the five activation policies. The first four policies require nothing from clients to work as expected; they are what we've had on X forever. The last policy does not work unless clients request activation as needed when they have a valid event. To my knowledge, both Windows and MacOS already require applications to request activation in this way, so cross-platform toolkits don't have to make a special case. This is the first requirement that was stated before: clients are responsible for requesting activation when it is appropriate. I have said nothing about stacking. Handling activation as I have described allows for every kind of stacking behavior I've seen, except for one: raise on frame clicks, but not on clicks within the frame. This exception exists when the compositor is not responsible for drawing the window frame, because nothing I have described allows the compositor to distinguish between parts of the client window. Make that distinction and the problem is solved; choose whichever stacking policy you would like. If the distinction between the frame and the rest of the window is included in the request for activation, you can even have clicks in the client raise, but only clicks on the frame activate, though I can think of no reason beyond sadism why anyone would make things work that way. I believe a simple stacking policy would be to allow a client with an active window to do anything it wants with its windows within the bounds set by other features; basically it can do anything as long as it doesn't put windows below stay-on-bottom features, like the desktop, or above stay-on-top features, like task bars and menus. I believe it would be sensible to keep the active window on top within its bounds, excepting for secondary windows, like tool palettes, which should stay above the primary window. This is the stacking behavior familiar to users of Windows and MacOS. I emphasize that the stacking policy is independent of the activation policy, so long as the compositor can distinguish between frames and their contents. The guides I gave before--clients request activation responsibly, compositors activate appropriately--allow all users to use their chosen compositors with any application targeted at Wayland. The combination of Windows/MacOS-style activation policy with an active-window-on-top stacking policy is the behavior familiar to Windows and MacOS users, including the allowance for beginning a drag-and-drop operation without raising the drag source window. Much the same system is possible on X11 if window managers will not grab buttons without modifiers and regular clients will use the globally active input model, requesting input focus when appropriate. Perhaps most important to many reading this list is that the all the activation policies familiar from X are compatible with the client behavior I have described. When I'm done with my current project at work, I'll be able to see about writing code for what I have described, but that's weeks or months away and then I'll need time to reacquaint myself with pretty much everything. I hope that this has been a useful message. I apologize for the lengthy lack of code. </blockquote></div> </div><div class="gmail_extra">Gregory, Thank you very much for your e-mail.� I think that helps a lot.� The lack of code is ok because I think Rafael is planning to start implementing as soon as things settle a bit.� Sometimes protocol discussions can end up with a whole lot of hypotheticals and what you gave was a very clear concise discussion of the topic. </div><div class="gmail_extra">If I am understanding you correctly, what we need are an "activate" request and "notify_active" and "notify_inactive" events.� To support sloppy focus, clients should just always try to activate on wl_pointer.enter and let the compositor sort it out unless they have a good reason to do otherwise.� For cases such as alt-tab, or another window closing, the compositor simply sends a notify_active.� I think I'm ok with this. Two more questions that come to mind: </div><div class="gmail_extra">1) Will we ever need a deactivate request?� Under the given scheme, no need comes immediately to mind. </div><div class="gmail_extra"> 2) Should the activate be associated with a particular seat.� If you have multiple cursors, you can easily have multiple active windows so this seems perfectly reasonable.� If this is the case, should this be part of wl_seat or should we keep it in xdg_shell?� I'm a little afraid to clutter wl_seat unnecessarily but this is very quickly starting to look like a seat focus. </div><div class="gmail_extra"> </div><div class="gmail_extra">Once again, Gregory, Thanks for the explanation.� I hope I'm following ok. </div><div class="gmail_extra">--Jason Ekstrand </div></div>