On Sat, Nov 2, 2013 at 11:50 AM, Jason Ekstrand <ja...@jlekstrand.net>wrote:
> On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre > <jstpie...@mecheye.net>wrote: > >> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand <ja...@jlekstrand.net>wrote: >> >> ... snip >> >> >>> 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. >>> >> >> No. Well, if we need it, let's add it later. >> >> 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. >>> >> >> I don't think windows need to know which seat they're active on, only >> that they're active on possibly one of them. From my eyes, there's nothing >> that prevents the compositor to send "notify_active" to more than one >> window at the same time for multiseat support. >> >> If I click on an unresponsive window A, we'll send a "click" event to >> that window, but since it's unresponsive, it won't activate. I might then >> decide to activate another window B, which will respond. When the window A >> becomes responsive again, it will process the "click" event and decide to >> send an "activate" request back. We need to make sure that this "rogue" >> client doesn't steal the focus, so the compositor needs to record the >> serial for the last "activate" event it got (sent by window B), and compare >> against it when it gets an "activate" event, besides whatever policies it >> might have. >> > > Here is the problem. Say you have two pointers P and Q and two and two > windows A and B. P clicks on A and A a is now active. Q clicks on B and > now B is active. Then P goes and clicks on B. However, B is already > active so it doesn't request an activation and A stays active with pointer > P. This assumes we are trusting clients to request activation. The other > option is that we simply force a click-always-activates model and clients > are constantly fighting the compositor just to make modal dialogues work. > "Already active"? All "notify active" means is "please draw me with a focused frame". The client should send an "activate" request on every button press if it wants to be focused when something clicks on it. As has said before, click-always-activate is broken: if I have window A activate, and I want to drag something from window B onto window A, we shouldn't activate window B on click. >> But serials are seat-specific, so we need the "activate" request to relay >> the seat back for the purposes of validating the timestamp. I don't think >> it makes sense to expose the active window on wl_seat, though. >> > > That's not correct. Timestamps are seat specific but timestamps are not > the same as serials. Timestamps are local to the seat. Serials are > actually compositor-global in weston and, in order to make things work, > should probably at least be client-global in other compositors. > I thought serials were intentionally *not* client-global, as we often compare serials from two different clients. But whether they're seat-global or compositor-global is something the specification doesn't say. We should probably clarify that somewhere. >> Once again, Gregory, Thanks for the explanation. I hope I'm following ok. >>> --Jason Ekstrand >>> >>> _______________________________________________ >>> wayland-devel mailing list >>> wayland-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> >>> >> >> >> -- >> Jasper >> > > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel