|
|
|
|
|
by speeddemon
1721 days ago
|
|
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... |
|