On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan <[email protected]>wrote:
> On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand <[email protected]> > wrote: > > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak <[email protected]> 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. I can > see > > not wanting to raise, but why not activate? > > 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. > 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. 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: 1) Will we ever need a deactivate request? Under the given scheme, no need comes immediately to mind. 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. Once again, Gregory, Thanks for the explanation. I hope I'm following ok. --Jason Ekstrand
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
