<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan <span dir="ltr"><<a href="mailto:gregory.merchan@gmail.com" target="_blank">gregory.merchan@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">On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>

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