tristan/kdeconnect-kde
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kdeconnect-kde/interfaces/systeminterfaces/org.freedesktop.portal.RemoteDesktop.xml

508 lines
21 KiB
XML
Raw Normal View History

Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
<?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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
This documentation describes version 2 of this interface.
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
-->
<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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
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.
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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>
<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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
<term>types u</term>
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
<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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
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>
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
</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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
For available device types, see the AvailableDeviceTypes property.
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
-->
<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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
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>
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
</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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
@state: New state of keyboard keycode
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Available keyboard keycode states:
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
<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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
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>
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +00:00
<!--
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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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 (cherry picked from commit 383ad27b5964c8ff14330bf702c68d1f9928f96f)
2024-01-28 14:00:05 +00:00
Use the RemoteDesktop portal to input from wayland Cross-desktop approach to moving the cursor remotely on wayland. Should work on X11 too, so we can consider drop the other one as well. It adds support for receiving full text as well, which didn't use to be possible.
2020-01-23 15:57:08 +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>
Reference in a new issue Copy permalink