[HMH]

> attempting to do it that way is just re-accumulating technical debt left over from X11

I see, I do not know much about the internal workings of Wayland. The problem I do see though is that screen recording is an essential feature that has been neglected for years due to the lack of a standard.

> This is a really bad idea, don't do this.

While I agree that getting window positions may be questionable, providing a human readable title for the streams that have been selected seems obvious, yet is missing.

> syncing issues with window sizes being reported incorrectly

This seems rather theoretical to me, while of course true, I doubt it is going to matter in practice.

> It's also a misuse of the screencasting API.

Hmm, do you think there is a better solution, that isn't giving up and having each desktop environment do its own thing?

> If you want to do this right now then you'll have to integrate with the specifics of the window manager or shell. There is no way around it, I really doubt you will get much interest in doing it another way.

This is also my conclusion, alas it's not happening and one of the reasons why I think Wayland is not quite there yet.

[speeddemon]

There is a standard API for screencasting and it works fine if you're only doing screencasting. Since the API is in the xdg portal, it sits at a layer above Wayland and X11 and in theory it should make it easier for you because it works the same on both of them and you could avoid writing window system specific code and just have one Linux backend using the xdg portal. But in practice it seems like your use case needed to access window system specific functionality anyway.

In my opinion, what you're asking for is an entirely new thing. You want an API for window management, but there has never really been a window management API on Linux, and every desktop environment was already doing its own thing. It has nothing to do with Wayland specifically. Under Xorg, the X11 APIs can sort of be hacked to do what you're asking under certain circumstances, and it might work ok on some window managers, but it's not going to work in every case. (And it doesn't play nicely with sandboxes either)

To get the human readable title seems like it would be an issue with how Mutter publishes the stream, i.e. not an issue with the portal itself. But I haven't looked into this enough in detail. I also don't know enough about your application to know why you would need the window sizes and positions. My only point is that if you intend to use that to draw an overlay over a screencast, or otherwise try to reconstruct what the compositing process is doing, then that's not going to be completely accurate. And it can't really be accurate without exposing various internals of how the compositor works, which puts any proposed API design back to square one...