[cycloptic]

>Wayland protocol is much more restrictive than X's -- things like screen capture and window managers don't work because the APIs they need aren't present

This is not quite true. There are protocols for these things in some implementations. You'd want to keep compatibility with these because otherwise you'd have no reason to be supporting Wayland. Keep in mind either way you're talking about using a specific compositor—it doesn't matter if the APIs aren't present in the protocol. In this situation you'd re-use one from another implementation or add another private protocol extension. That's always been what individual compositors are encouraged to do. It's no different here.

[csande17]

> This is not quite true. There are protocols for these things but they live in multiple places.

Every Wayland window-manager-compositor-hybrid invents their own protocols for these things. This basically means that you can't write a program that does these things -- you need three different versions of every API call you make, and that's just to support the popular desktop environments that people happen to be using this week. So no one has, so the only Wayland protocol features you need to support are the basic ones to open a window, draw into it, and get mouse and keyboard input.

> Keep in mind either way you're talking about using a custom compositor

No, I suspect the "top-level compositor" could be any off-the-shelf Wayland compositor that supports XWayland and can make a window full-screen.

[cycloptic]

Here is the thing: it's trivial to map those basic features back to X. That's already mostly been done. If you continue with that solution you'll have the same problem in reverse—assuming X support ever gets removed from the toolkits, then in that situation you'll get Wayland apps that depend on some Wayland functionality that doesn't work. See what I mean?

(IMO we're pretty far off from X support being removed if it ever even happens, so I wouldn't worry too much about that right now)

And I actually don't think it's a big deal that there are separate implementations. You can absolutely still write programs that do these things, and people do. Usually you start with targeting just one implementation and then you port it to the others. All you need is an API to abstract the custom protocols. A lot of those differences are already abstracted in the portals API which has those three separate implementations so you may not even need to do any porting if that fits. Worst case, if something isn't in the portals API then you have some three clause switch statements when you make protocol requests. Then after you stabilize it, move those switch statements into a library and then other people can use it as an abstraction layer, and nobody needs to write the switch statements again. Yeah it's work, but for an app developer it's actually easier to do that than getting all the upstreams to standardize everything.