On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre <[email protected]>wrote:
> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand <[email protected]>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. > > 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. > > 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 >> >> > > > -- > Jasper >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
