Why isn't Xwayland just a Wayland client?

[Joseph Burt]

On Wed, Sep 6, 2017 at 4:45 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> Popups (e.g. menus) in Wayland use protocol that provides the server
> with:
> - the relationship to the window which the popup is for, and
> - the input event identity that triggered the popup.
>
> These are required on Wayland: the parent window is required for
> positioning and stacking, and the input event identity determines
> whether the popup is valid.
>
> X11 protocol does not necessarily provide these. On X11, the client
> puts a window at x,y and makes an input grab. That's it.
>
> You would have to infer from x,y and the X11 window stack which X11
> window might be the parent (if it even exists) and guess what input
> event might have triggered the popup (there might not be any) to be
> able to translate that into Wayland.
>
> Xwayland would also need to guess that the input grab is related to
> showing the window to be able to combine the two actions into a popup
> request on Wayland.
>
> I hope this gives you an idea why it is so hard to try to translate
> window management from X11 to Wayland protocol. Writing an X11 window
> manager is extremely painful to begin with, making one that can
> translate into Wayland is much more painful because of the fundamental
> design differences. The "out-of-band" design of putting an X11 WM in a
> Wayland compositor and using X11 to manage X11 windows is the
> compromise to get things working.

You're absolutely right, X clients will never use Wayland's builtin
popup and transient logic, and with all of X's quirks, there will
always have to be an X server somewhere.

Where does the whole construction fail if the little bit of XWM logic
is in Xwayland? Going a little farther, I'm imagining toplevel X
client windows, clients isolated or not, arranged in the (essentially
arbitrary and virtual) X coordinate space such that none overlap, each
corresponding with a wl_surface, with everything on top done by the X
server and/or via subsurfaces. That leaves the little WM shim dealing
with decoration if required, close, resize, and grabs. How the
compositor positions or stacks is irrelevant.

Cheers,
Joseph