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. On Tue, Oct 13, 2015 at 9:48 AM, Bill Spitzak <spit...@gmail.com> wrote: > On 10/08/2015 01:00 PM, Daniel Stone wrote: >> >> Hi, >> >> On 8 October 2015 at 08:27, Jonas Ådahl <jad...@gmail.com> wrote: >>> >>> On Mon, Oct 05, 2015 at 12:04:49PM -0500, Derek Foreman wrote: >>>> >>>> There are cases in weston where it would be quite nice to have a >>>> sentinel value to use instead of having to have a bool for "this serial >>>> number is legit" too. >>> >>> >>> Even though probably unlikely, for clients unaware of a possible 0 == no >>> serial, this would mean that they would suddenly start to be killed when >>> when they before worked just fine. > > > Clients cannot be killed when they pass bad serial numbers. They don't > really know what events the compositor accepts for a present request, so > passing the wrong one cannot kill it. > > I suppose a compositor could record the serial number of every event sent to > the client so it could make sure the request only contained actual ones, but > I don't think anybody is going to implement a compositor that way. I expect > compositors will check to see if the event is the last mouse-down or > mouse-up sent to the client and not remember any other history. > >>> Is it really a big deal to have to multiple requests that do things >>> differently? >> >> >> Let's try to solve this empirically, then - which optional-serial >> requests do we have apart from present/needs-attention here, and what >> does/would the difference look like semantically? > > > I agree that if there really is different behavior then there should be two > requests. > > But, do you really, really, really believe that any actual usable compositor > is going to treat the no-event present differently than a serial for an > event that should not raise the window (such as a mouse enter event)? > > If you think so, please describe carefully exactly why. Since hostile > clients can call the no-event request, stopping them is not a reason. > Non-hostile clients will avoid sending nonsense events to the present > request. > > I don't think this will happen, therefore the need for two calls here is > false. > > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel