In one case, an invalid serial dictates that the window should have it's focus attempts prevented. In the no-serial case, focus world be stolen.
On Tue, Oct 13, 2015, 10:25 AM Bill Spitzak <spit...@gmail.com> wrote: > On 10/13/2015 09:53 AM, Jasper St. Pierre wrote: > > The goal of focus-stealing prevention isn't to prevent hostile clients > > from stealing the focus. It's to allow friendly clients to upgrade the > > experience if they can track the originating event that originally > > opened a window. For instance, if I launch GIMP but then go back to > > typing in a terminal, after GIMP launches, it shouldn't steal the > > focus, because I've interacted with another window since then. > > > > We've tried turning off focus-stealing prevention for all new windows > > without a timestamp, and it provided a very unfun experience. Lots of > > applications either don't have an originating user action when they > > pop up a window, or they don't track it thoroughly. > > > > Perhaps GUI applications have gotten substantially better in the 6 > > years ago since we tried it -- I'd be willing to run the experiment > > again. But I don't expect much changing. > > Yes but this is still not answering my question. > > Can you describe a design where no-event is treated *differently* than > an unknown or disallowed event in the _present request? > > You are describing how they would be treated identically. I suspect that > will always happen, but the idea that they can be treated differently is > being used as an excuse to not add the special no-event serial of zero > and reduce the number of _present messages from 2 to 1. > > > >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel