kdeconnect-kde/interfaces/systeminterfaces/org.freedesktop.portal.RemoteDesktop.xml

508 lines
21 KiB
XML
Raw Permalink Normal View History

<?xml version="1.0"?>
<!--
Copyright (C) 2017-2018 Red Hat, Inc.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
You should have received a copy of the GNU Lesser General Public
License along with this library. If not, see <http://www.gnu.org/licenses/>.
-->
<node name="/" xmlns:doc="http://www.freedesktop.org/dbus/1.0/doc.dtd">
<!--
org.freedesktop.portal.RemoteDesktop:
@short_description: Remote desktop portal
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
The Remote desktop portal allows to create remote desktop sessions.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
This documentation describes version 2 of this interface.
-->
<interface name="org.freedesktop.portal.RemoteDesktop">
<!--
CreateSession:
@options: Vardict with optional further information
@handle: Object path for the #org.freedesktop.portal.Request object representing this call
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Create a remote desktop session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
A remote desktop session is used to allow remote controlling a desktop
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
session.
A remote desktop session may only be started and stopped with this interface,
but you can use the #org.freedesktop.portal.Session object created with this
method together with certain methods on the #org.freedesktop.portal.ScreenCast and
#org.freedesktop.portal.Clipboard interfaces. Specifically, you can call
org.freedesktop.portal.ScreenCast.SelectSources() to also get screen content,
and org.freedesktop.portal.ScreenCast.OpenPipeWireRemote() to acquire a file
descriptor for a PipeWire remote. See #org.freedesktop.portal.ScreenCast for
more information on how to use those methods. To capture clipboard content,
you can call org.freedesktop.portal.Clipboard.RequestClipboard(). See
#org.freedesktop.portal.Clipboard for more information on the clipboard
integration.
Supported keys in the @options vardict include:
<variablelist>
<varlistentry>
<term>handle_token s</term>
<listitem><para>
A string that will be used as the last element of the @handle. Must be a valid
object path element. See the #org.freedesktop.portal.Request documentation for
more information about the @handle.
</para></listitem>
</varlistentry>
<varlistentry>
<term>session_handle_token s</term>
<listitem><para>
A string that will be used as the last element of the session handle. Must be a valid
object path element. See the #org.freedesktop.portal.Session documentation for
more information about the session handle.
</para></listitem>
</varlistentry>
</variablelist>
The following results get returned via the #org.freedesktop.portal.Request::Response signal:
<variablelist>
<varlistentry>
<term>session_handle o</term>
<listitem><para>
The session handle. An object path for the
#org.freedesktop.portal.Session object representing the created
session.
</para></listitem>
</varlistentry>
</variablelist>
-->
<method name="CreateSession">
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In0" value="QVariantMap"/>
<arg type="o" name="handle" direction="out"/>
</method>
<!--
SelectDevices:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@handle: Object path for the #org.freedesktop.portal.Request object representing this call
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Select input devices to remote control.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Supported keys in the @options vardict include:
<variablelist>
<varlistentry>
<term>handle_token s</term>
<listitem><para>
A string that will be used as the last element of the @handle. Must be a valid
object path element. See the #org.freedesktop.portal.Request documentation for
more information about the @handle.
</para></listitem>
</varlistentry>
<varlistentry>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
<term>types u</term>
<listitem><para>
Bitmask of what device types to request remote controlling of.
Default is all.
</para></listitem>
</varlistentry>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
<varlistentry>
<term>restore_token s</term>
<listitem><para>
The token to restore a previous session.
If the stored session cannot be restored, this value is ignored
and the user will be prompted normally. This may happen when, for
example, the session contains a monitor or a window that is not
available anymore, or when the stored permissions are withdrawn.
The restore token is invalidated after using it once. To restore
the same session again, use the new restore token sent in response
to starting this session.
This option was added in version 2 of this interface.
</para></listitem>
</varlistentry>
<varlistentry>
<term>persist_mode u</term>
<listitem><para>
How this session should persist. Default is 0. Accepted values are:
<simplelist>
<member>0: Do not persist (default)</member>
<member>1: Permissions persist as long as the application is running</member>
<member>2: Permissions persist until explicitly revoked</member>
</simplelist>
If the permission for the session to persist is granted, a restore token will
be returned via the #org.freedesktop.portal.Request::Response signal of the
start method used to start the session.
This option was added in version 2 of this interface.
</para></listitem>
</varlistentry>
</variablelist>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
For available device types, see the AvailableDeviceTypes property.
-->
<method name="SelectDevices">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="o" name="handle" direction="out"/>
</method>
<!--
Start:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@parent_window: Identifier for the application window, see <link linkend="parent_window">Common Conventions</link>
@options: Vardict with optional further information
@handle: Object path for the #org.freedesktop.portal.Request object representing this call
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Start the remote desktop session. This will typically result in the portal
presenting a dialog letting the user select what to share, including
devices and optionally screen content if screen cast sources was
selected.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Supported keys in the @options vardict include:
<variablelist>
<varlistentry>
<term>handle_token s</term>
<listitem><para>
A string that will be used as the last element of the @handle. Must be a valid
object path element. See the #org.freedesktop.portal.Request documentation for
more information about the @handle.
</para></listitem>
</varlistentry>
</variablelist>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
The following results get returned via the
#org.freedesktop.portal.Request::Response signal:
<variablelist>
<varlistentry>
<term>devices u</term>
<listitem><para>
A bitmask of the devices selected by the user.
</para></listitem>
</varlistentry>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
<varlistentry>
<term>clipboard_enabled b</term>
<listitem><para>
A boolean for whether the clipboard was enabled ('true') or not ('false').
See the #org.freedesktop.portal.Clipboard documentation for more information.
Since version 2.
</para></listitem>
</varlistentry>
<varlistentry>
<term>restore_token s</term>
<listitem><para>
The restore token. This token is a single use token that can later
be used to restore a session. See
org.freedesktop.portal.RemoteDesktop.SelectDevices() for details.
This response option was added in version 2 of this interface.
</para></listitem>
</varlistentry>
</variablelist>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
If a screen cast source was selected, the results of the
#org.freedesktop.portal.ScreenCast.Start response signal may be
included.
-->
<method name="Start">
<arg type="o" name="session_handle" direction="in"/>
<arg type="s" name="parent_window" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In2" value="QVariantMap"/>
<arg type="o" name="handle" direction="out"/>
</method>
<!--
NotifyPointerMotion:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@dx: Relative movement on the x axis
@dy: Relative movement on the y axis
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Notify about a new relative pointer motion event. The (dx, dy) vector
represents the new pointer position in the streams logical coordinate
space.
-->
<method name="NotifyPointerMotion">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="d" name="dx" direction="in"/>
<arg type="d" name="dy" direction="in"/>
</method>
<!--
NotifyPointerMotionAbsolute:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@stream: The PipeWire stream node the coordinate is relative to
@x: Pointer motion x coordinate
@y: Pointer motion y coordinate
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Notify about a new absolute pointer motion event. The (x, y) position
represents the new pointer position in the streams logical coordinate
space (see the logical_size stream property in
#org.freedesktop.portal.ScreenCast).
-->
<method name="NotifyPointerMotionAbsolute">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="u" name="stream" direction="in"/>
<arg type="d" name="x" direction="in"/>
<arg type="d" name="y" direction="in"/>
</method>
<!--
NotifyPointerButton:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@button: The pointer button was pressed or released
@state: The new state of the button
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
The pointer button is encoded according to Linux Evdev button codes.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if POINTER access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Available button states:
<simplelist>
<member>0: Released</member>
<member>1: Pressed</member>
</simplelist>
-->
<method name="NotifyPointerButton">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="i" name="button" direction="in"/>
<arg type="u" name="state" direction="in"/>
</method>
<!--
NotifyPointerAxis:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@dx: Relative axis movement on the x axis
@dy: Relative axis movement on the y axis
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
The axis movement from a 'smooth scroll' device, such as a touchpad.
When applicable, the size of the motion delta should be equivalent to
the motion vector of a pointer motion done using the same advice.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if POINTER access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Supported keys in the @options vardict include:
<variablelist>
<varlistentry>
<term>finish b</term>
<listitem><para>
If set to true, this is the last axis event in a series, for
example as a result of the fingers being lifted from a touchpad
after a two-finger scroll. Default is false.
</para></listitem>
</varlistentry>
</variablelist>
-->
<method name="NotifyPointerAxis">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="d" name="dx" direction="in"/>
<arg type="d" name="dy" direction="in"/>
</method>
<!--
NotifyPointerAxisDiscrete:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@axis: The axis that was scrolled
@steps: The number of steps scrolled
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if POINTER access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Available axes:
<simplelist>
<member>0: Vertical scroll</member>
<member>1: Horizontal scroll</member>
</simplelist>
-->
<method name="NotifyPointerAxisDiscrete">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="u" name="axis" direction="in"/>
<arg type="i" name="steps" direction="in"/>
</method>
<!--
NotifyKeyboardKeycode:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@keycode: Keyboard code that was pressed or released
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
@state: New state of keyboard keycode
May only be called if KEYBOARD access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Available keyboard keycode states:
<simplelist>
<member>0: Released</member>
<member>1: Pressed</member>
</simplelist>
-->
<method name="NotifyKeyboardKeycode">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="i" name="keycode" direction="in"/>
<arg type="u" name="state" direction="in"/>
</method>
<!--
NotifyKeyboardKeysym:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@keysym: Keyboard symbol that was pressed or released
@state: New state of keyboard keysym
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if KEYBOARD access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Available keyboard keysym states:
<simplelist>
<member>0: Released</member>
<member>1: Pressed</member>
</simplelist>
-->
<method name="NotifyKeyboardKeysym">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="i" name="keysym" direction="in"/>
<arg type="u" name="state" direction="in"/>
</method>
<!--
NotifyTouchDown:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@stream: The PipeWire stream node the coordinate is relative to
@slot: Touch slot where touch point appeared
@x: Touch down x coordinate
@y: Touch down y coordinate
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if TOUCHSCREEN access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Notify about a new touch down event. The (x, y) position
represents the new touch point position in the streams logical
coordinate space (see the logical_size stream property in
#org.freedesktop.portal.ScreenCast).
-->
<method name="NotifyTouchDown">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="u" name="stream" direction="in"/>
<arg type="u" name="slot" direction="in"/>
<arg type="d" name="x" direction="in"/>
<arg type="d" name="y" direction="in"/>
</method>
<!--
NotifyTouchMotion:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@stream: The PipeWire stream node the coordinate is relative to
@slot: Touch slot where touch point appeared
@x: Touch motion x coordinate
@y: Touch motion y coordinate
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if TOUCHSCREEN access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Notify about a new touch motion event. The (x, y) position
represents where the touch point position in the streams logical
coordinate space moved (see the logical_size stream property in
#org.freedesktop.portal.ScreenCast).
-->
<method name="NotifyTouchMotion">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="u" name="stream" direction="in"/>
<arg type="u" name="slot" direction="in"/>
<arg type="d" name="x" direction="in"/>
<arg type="d" name="y" direction="in"/>
</method>
<!--
NotifyTouchUp:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@slot: Touch slot where touch point appeared
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
May only be called if TOUCHSCREEN access was provided after starting the
session.
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
Notify about a new touch up event.
-->
<method name="NotifyTouchUp">
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="u" name="slot" direction="in"/>
</method>
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
<!--
ConnectToEIS:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@fd: A file descriptor to an EIS implementation that can be passed to a libei sender context
Request a connection to an EIS implementation. The returned handle can
be passed to ei_setup_backend_fd() for a libei sender context to
complete the connection. All information about available devices and the
event flow is subject to libei. Please see the libei documentation for details.
This method may only be called once per session, where the EIS
implementation disconnects the session should be closed.
This method must be called after #org.freedesktop.portal.RemoteDesktop.Start()
Once an EIS connection is established, input events must be sent exclusively via
the EIS connection. Any events submitted via NotifyPointerMotion,
NotifyKeyboardKeycode and other Notify* methods will return an error.
To see how to pair a PipeWire stream with a libei device region, see the
documentation for the mapping_id stream property in
#org.freedesktop.portal.RemoteDesktop.Start().
This method was added in version 2 of this interface.
-->
<method name="ConnectToEIS">
<annotation name="org.gtk.GDBus.C.Name" value="connect_to_eis"/>
<annotation name="org.gtk.GDBus.C.UnixFD" value="true"/>
<arg type="o" name="session_handle" direction="in"/>
<arg type="a{sv}" name="options" direction="in"/>
<annotation name="org.qtproject.QtDBus.QtTypeName.In1" value="QVariantMap"/>
<arg type="h" name="fd" direction="out"/>
</method>
<!--
AvailableDeviceTypes:
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
A bitmask of available source types. Currently defined types are:
[plugins/mousepad]: Add support for the persistence feature of the RemoteDesktop portal This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call. Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal. Things that need to be checked: - What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)? - In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it - Seems fine with xdg-desktop-portal 1.14.4 at least - For the Start call we'll need to handle the case of the user denying the persistence request anyway - Where and how should the restore token be stored? - ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~ - Updated to use `KSharedConfig::openStateConfig` - Most of KDE Connect's settings and data appear to be for each connected device - The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h` BUG: 479013
2024-01-28 14:00:05 +00:00
<simplelist>
<member>1: KEYBOARD</member>
<member>2: POINTER</member>
<member>4: TOUCHSCREEN</member>
</simplelist>
-->
<property name="AvailableDeviceTypes" type="u" access="read"/>
<property name="version" type="u" access="read"/>
</interface>
</node>