Supporting org.freedesktop.RemoteDesktop1

[David Edmundson]

I should be transparent here that Cendio (TigerVNC people) are funding
the work above on making a KDE implementation.

> Makes sense  to iterate. It's a bit weird to add it on top rather than
> deprecating other approaches but I guess time will tell.
>
> I see this doesn't seem to go through XDG Desktop Portal like the
> former one.

The intention is that it's only for super trusted services.

One rationale given from the Mutter side is they don't want to be
parsing keyboard maps from anything untrusted and that when this is
running you would potential disable kscreen + disable user settings
for keyboard setting controls and so on.

You don't want every random app doing that, so that makes some sense.

There's also the issue of prompts, though we do have a KDE mechanism
for that, that part feels like NIH.

>Will this one be fine for flatpak apps? I see the spec
> distances a bit from the use-case but it makes me wonder what the
> use-case looks like:

Supporting in RustDesk or whatever should relatively trivial. it's
similar to the portal but you change some paths and names. I
Shipping in a flatpak I think is still viable, but would require an
explicit manifest permission to org.freedesktop.remote1 dbus service
rather than the portal.

It does seem a bit of giving up on the portal, but we'd need a remote
portal v2 for our needs anyway, so does it matter if it goes via the
portal or directly? The only user/app facing difference it gives is
whether we support static vs runtime permission granting, and I can't
see a good use case for runtime here.

David