feat: Support Remote Desktop token persistance - #8865

I'm looking forward to using this feature!

I get an error on Arch+KDE: [2025-08-19T09:35:03] ERROR: failed to initialize remote desktop session: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Restore token is not a valid UUID string

Edit: Seems to work on GNOME though, amazing! I wonder... how do I un-remember the decision?

Um to remove remember involves using the desktop to clear it. The easiest way is to (for now) is to remove the xdgRestoreToken entry from the client section of the settings file.

Ill maybe add a setting to clear it in our gui. But this is something your desktop should provide a settings area for like the kde flatpak permission kcm.

Odd as its fine on my kde machine the restore key (in settings) should be a uuid .. did you use the QtPortals branch on that machine that branch write a non UUID token for the same value (if so just clear it out)

did you use the QtPortals branch on that machine that branch write a non UUID token for the same value (if so just clear it out)

Turns out I had a borked libportal.so, reinstalling fixed it: sudo pacman -S xdg-desktop-portal

Um to remove remember involves using the desktop to clear it. The easiest way is to (for now) is to remove the xdgRestoreToken entry from the client section of the settings file.

Yes, this clears it. I edited /home/nick/.config/Deskflow/Deskflow.conf and removed the xdpRestoreToken= line.

Ill maybe add a setting to clear it in our gui.

I think manually editing the .conf is good enough, but maybe we should document that at least?

I think manually editing the .conf is good enough, but maybe we should document that at least?

Added to https://github.com/deskflow/deskflow/wiki/Workarounds#Remove-Xdg-Remote-Desktop-permission

IMHO There is no reason to ever allow input capture always (i.e server).

depends on your setting but either way xdg-desktop-portal#1768 would address that.

That's an orthogonal problem to the token persistence though (token persistence is also used for "allow reconnect" after a previous ack, for some value of "after". As opposed to "allow unquestioned connect", two subtly different problems).