Open Martmists-GH opened 3 months ago
Mikenux
commented
3 months ago Hello @Martmists-GH!
I think the first improvement is to have what is needed in the portal so that we only have one session restore window instead of multiple ones, while still being able to be selective in what is restored.
Regarding the behavior you expect, there is the following issue: https://github.com/flatpak/xdg-desktop-portal/issues/1064.
Martmists-GH
commented
2 months ago I think rather than avoiding multiple windows, being able to restore automatically without a window would be much more beneficial.
Mikenux
commented
2 months ago Don't forget the other issue I mentioned which is about window tracking :wink:.
In this issue, it's about the user defining which specific windows (using their titles) to track. The same can be done for session restore (at least for windows), but we ask again when the session has changed (e.g. a new source has been added) to protect against the app possibly recording windows that we removed from sources (since sources are not removed with the portal).
Mikenux
commented
2 months ago Mistakes here from me.
In GNOME, currently, the portal asks only when relevant windows are no longer available. Making them available before launching OBS restore the corresponding sources automatically. I think that makes sense as a way to handle removed sources. If the behavior you described concerns OBS not automatically restoring the session when launched while the corresponding windows are still available, this seems to be a bug which is apparently recognized in the kde bug you linked.
If you want to restore the session when OBS is running and the corresponding windows become available (i.e. during the session they were closed but you reopened them), the only way is to explicitly ask which sources to track, and to be clear on how to remove this tracking (removing source tracking can't be done within app UI). This issue is then the same as #1064 as I already said.
YellowOnion
commented
1 month ago The issue is that OBS wants to save sessions and instantly restore them, with possible multiple different windows being captured at once, this needs to persist between restarts of the compositor, it seems quite difficult to do this without the client providing UUIDs for each different "kind" of window, that the window manager can match against, and then provide a handle for OBS, that can be persisted to disk by the compositor.
It's quite hard to match against windows for example, inside sway for auto placement, most windows within an app look pretty similar except for a transient handle provided, and extremely fickle title that changes based on all sorts of random decisions by the app designer...for example you might want to capture a firefox session with a specific user or profile that you can use safely for recording, but the title can and will change due to any arbitrary website's choice, it's not at all secure.
I would go as far to say it needs a wayland extension to provide metadata that can establish some concrete metadata to match against.
jadahl
commented
1 month ago I would go as far to say it needs a wayland extension to provide metadata that can establish some concrete metadata to match against.
That would probably be https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/238 .
Perhaps a portal backend could automatically add any window from a previous saved session that would be restored if it was available when the restored session was created.
Mikenux
commented
1 month ago you might want to capture a firefox session with a specific user or profile that you can use safely for recording, but the title can and will change due to any arbitrary website's choice, it's not at all secure.
What do you mean by "use safely for recording" and "not at all secure"? If you're worried about recording wrong content, note that the content of a website or window can also change. For a secure recording, that is a recording that the app is not going to share, you need a fully (and truly) sandboxed app. However, it's a different story for streaming.
Operating System
Arch Linux
XDG Desktop Portal version
1.18
XDG Desktop Portal version (Other)
No response
Desktop Environment
KDE
Desktop Environment (Other)
No response
Expected Behavior
OBS keeps a reference to the previous window title/application and captures it when it becomes available
Current Behavior
Currently, window capture in OBS opens a popup for every window, instead of remembering the last known application like it does on X11.
Steps to Reproduce
Anything else we should know?
In the OBS community they said it was a Wayland issue, on the Wayland git they said it was an application or compositor issue. The OBS maintainers said it was an issue with xdg-desktop-portal.
See also: