Extend persist/restore_token concept to RemoteDesktop #850
Comments
GeorgesStavracas
added
the
new api
|
This would be a welcome addition to a "pair programming" application I work on. It aims to make pair programming remotely as seamless as possible. It's common for users to switch who is "hosting" (the one sharing their screen) throughout a pairing session. Having to give permission to our app each time the "host user" changes makes the transition less seamless. Using a restore token means users could switch who is sharing their screen multiple times without having to ask the user for the same permissions each time. |
|
I'm currently looking into how it can be done. The idea I have now is to use the same restore token like API that ScreenCast has, but make it part of SelectDevices. When used with SelectDevices, it'd also restore the screen cast source, in addition to devices, and and store the permission/source data in a |
This adds persistent remote desktop sessions similar to persistent screen cast sessions. What it means is that applications can ask for sessions to be "saved" either temporarily in the portal, or in the permission store, and later be restored at will, without any interactive dialog showing up. It works the same way, by the Start() method returning a restore token, and similarly to the screen cast variant, passing the same restore token to the SelectDevices() method the next time. Closes: flatpak#850
|
See #1004. |
This adds persistent remote desktop sessions similar to persistent screen cast sessions. What it means is that applications can ask for sessions to be "saved" either temporarily in the portal, or in the permission store, and later be restored at will, without any interactive dialog showing up. It works the same way, by the Start() method returning a restore token, and similarly to the screen cast variant, passing the same restore token to the SelectDevices() method the next time. Closes: flatpak#850
This adds persistent remote desktop sessions similar to persistent screen cast sessions. What it means is that applications can ask for sessions to be "saved" either temporarily in the portal, or in the permission store, and later be restored at will, without any interactive dialog showing up. It works the same way, by the Start() method returning a restore token, and similarly to the screen cast variant, passing the same restore token to the SelectDevices() method the next time. Closes: flatpak#850
This adds persistent remote desktop sessions similar to persistent screen cast sessions. What it means is that applications can ask for sessions to be "saved" either temporarily in the portal, or in the permission store, and later be restored at will, without any interactive dialog showing up. It works the same way, by the Start() method returning a restore token, and similarly to the screen cast variant, passing the same restore token to the SelectDevices() method the next time. Closes: flatpak#850
This adds persistent remote desktop sessions similar to persistent screen cast sessions. What it means is that applications can ask for sessions to be "saved" either temporarily in the portal, or in the permission store, and later be restored at will, without any interactive dialog showing up. It works the same way, by the Start() method returning a restore token, and similarly to the screen cast variant, passing the same restore token to the SelectDevices() method the next time. Closes: #850
File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.portal.Error.InvalidArgument: Remote desktop sessions cannot persist
It would be important to remotely access unattended machines.
The text was updated successfully, but these errors were encountered: