The plugin should always be loaded, as:
- we can provide a virtual display over VNC, even if the device isn't capable to use virtual displays itself (`krfb-virtualmonitor`)
- we would do the capabilities check regardless, if !670 gets merged
- hiding the DBus path doesn't trigger the `PluginChecker.qml` to think the plugin is unavailable, it just doesn't work
- -> is this a bug or intended behaviour?
BUG: 485829
## Summary
Currently, the plugin just fails silently if the local device is missing the `krfb` package or if the remote device misses an `vnc://` protocol/scheme handler. You click the button and nothing happens.
One issue is, that the plugin is considered `virtualmonitor.available` in the `DeviceDelegate.qml`, even if the check for `krfb-virtualmonitor` fails and no dbus-path is provided. I investigated the behavior a bit, but ignored it in the end as this MR benefits from being shown for device constellations that _could_ provide this feature.
A warning is shown with brief instructions, how to get the plugin working correctly.
- Check if krfb-virtualmonitor is available locally
- Check default scheme handler for vnc:// on device (Linux)
- Show warnings / reasons, if no connection could be established
## Test Plan
Regarding if the devices have mentioned packages installed, we should see different behaviors.
If the remote device has no VNC client, it can not connect to out server. _A warning should be shown._
If the local device hasn't the `krfb-virtualmonitor` available, the remote device couldn't connect. _A warning should be shown._
If both problems are present, _both warnings should be shown._
If none of these are present, no warning should be shown and we should try to establish a connection.
The connection attempts failed? _A warning should be shown._
BUG: 485830
The current implementation of the plugin is severly broken.
1. The generated URL links to the localhost
2. The port is not set
-----
The URL is now generated on the request receiving side, not send in the request.
This allows finding a valid IP address.
Furthermore, I changed the protocol by splitting it up. This could become useful, if we ever want to support other rdp protocols/platforms.
Note: This is a breaking change, but the current implementation is not working at all.. so it does not actually break something.
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
To use -ldbus, the value of ${DBus_LIBARARY_DIR} would also need to be
added to the linker search paths.
To get around this, simply use the imported target by pkgconfig.
[1] b8b30ba571
As discussed in Matrix and BUG: 474121 this plugin is confusing (because
it doesn't actually take a photo, it just launches the camera on your
phone) and its use case can be covered by taking a photo and sharing it,
which only requires a couple extra clicks.
This sends generic multimedia keyboard events, since the implementation
using GlobalSystemMediaTransportControlsSessionManager had some problems:
the SessionsChanged event doesn't work on recent Windows versions,
plus many players don't implement this API (eg: VLC, Windows Media).
This is far less code and allows for an easier enforcing of standards, for
example the name of the log identifiers which were adjusted in a few cases.
Also clean up unused includes when noticed.
Those plugins re really simple and don't need any initialization logic.
With the using statement, we do not need to add a constructor and pass the parent/args to the baseclass
By commenting out the parameter name, we get compile-time checks
Also, we can omit them for slots and Qt will not forward the parameters.
In case we had TODOs next to the code, I kept the Q_UNUSED statements
for now.
Overriding and defaulting them in the header doesn't make sense
For the dbus interfaces, we don't have any reasources to clean up or memory to be released. Meaning we can drop those lines too
- Using QLatin1String when concatinating strings is faster, because they
are more lightweight. For the resulting string, we need to allocate
new memory anyway
- Use QLatin1String overloads where they are provided by Qt APIs
- Just use const char* for log messages, the quoting of QStrings is not
needed
- Make sure to reuse string results when possible
- We do not need the return type. If a plugin declares it can handle the
packet it should do so. We don't have any fallback logic in place and
the packet types are namespaced with the plugin IDs anyway.
- Provide a default implementation with a warning, not all plugins need
to overwrite this
The rationale is explained in https://planet.kde.org/friedrich-kossebau-2023-06-28-include-also-moc-files-of-headers/
In case of KDEConnect, it impressively speeds up compilation. Before it
took 390 seconds on a clean build and with this change it took 330 seconds.
This is due to the mocs_compilation having to include the header files
and thus all their headers. Due to the lots of small plugins we have,
this means that the same headers must be compiled plenty of times.
When we include the moc files directly in the C++ file, they are already
available.
