On Mon, 2016-07-04 at 03:10 -0400, Olivier Fourdan wrote: > That mechanism would probably not work as is with O-R windows for a > couple of reasons:
Your descriptions here seem to assume the inability to fix the compositor, which to me seems... insane? _Nothing_ xserver can do in this situation is going to make this be handled reasonably all on its own, we have to assume a cooperative compositor. So... > - the WM is not supposed to manage O-R windows (well, a compositor > has of course, but the WM doesn't get a MapRequest and most WM will > do as little as possible with O-R). Yes, a traditional X window manager will mostly ignore o-r windows. But a compositor has to draw them, and under xwayland must also route input to them. Which means the compositor has the opportunity to _not_ draw them and _not_ route input to them. > - O-R are not listed in the window list so even if the compositor > would have set the demand attention flag, the shell would probably > ignore it. Again: that it is not in the window list does not mean it could not be in the window list. > Besides, what happens here is that O-R is already covering the entire > screen (thus most likely cover any shell notification as well), and > it feels natural for the user to start typing as the screen is > covered and a nice text input is displayed :) Again: that it is painted and responds to input is not mandatory. The conditions described here (o-r, the size of an output, etc) are things the compositor is aware of before it decides to map the wayland surface. X can give it more information (GrabNotify or whatever), but X can only request politely that wl behave nicely. > We do (well, in gtk-shell no not strictly standard) have a "present" > protocol that allows a Wayland client to ask the compositor to raise > and focus a surface, we could use this with Xwayland to achieve that, > but I suspect mutter would most likely deny such request on O-R (and > being gtk-shell, that wouldn't work with any other compositor). Sure, I wouldn't want to depend on gtk_shell either. Perhaps a better idea is to write our own x11_compatibility protocol and use it if it's there. The compositor would of course be free to honor that protocol only for Xwayland servers it happens to be managing, or to not implement it at all if it doesn't care about mixed x11 and native wayland surfaces. > Thing is, weston seems to do this right so there should be a way to > achieve that in mutter as well. > > The approach I took in my patch for GNOME bug https://bugzilla.gnome. > org/show_bug.cgi?id=752956 is to not deny focus for O-R that are > fullscreen (either on a single monitor or the whole screen): > > https://bugzilla.gnome.org/attachment.cgi?id=330053&action=diff > > It does fix the issue, but I am not sure this can be acceptable in > GNOME. If gnome considers purity of essence to be more important than correct functionality, well, that's an opinion they can have I guess. I'm happy to see X extended to give the compositor more information and better control. But I don't see a reasonable way of fixing this entirely within xserver. The compositor has to want to get this right. - ajax _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel