[speeddemon]

>I still can not fathom how Wayland could even exist this long without any decent way to do screen recording and I also do not get why there is no official protocol or at least extension for this!

It likely won't ever get an official Wayland extension, for a number of reasons. Screen capturing is inherently insecure and so it shouldn't really be happening over the Wayland socket. It also doesn't need to happen over the Wayland socket or be related to the windowing protocol at all, attempting to do it that way is just re-accumulating technical debt left over from X11.

>I fear that this means if flatpak does not need a feature, even if it makes sense in another context, it probably won't ever be implemented.

I wouldn't think of it so much as just flatpak, but the API needs to be usable from within a sandbox, and it needs to be done in such a way that it can be reasonably presented to the user.

>For example something I require for my project are proper window names and their position

This is a really bad idea, don't do this. This is guaranteed to mess with the window manager and run into any number of syncing issues with window sizes being reported incorrectly. It's also a misuse of the screencasting API. I checked the issues you posted and I don't think you're going to get much farther trying to hack around the API. 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.

[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...