If you lock the screen in EndeavourOS, a signal KSystemClipboard:changed is emitted with empty text and clipboard mode QClipboard::Clipboard. Upon unlock the clipboard will be re-synced.
A clipboard network packet will be sent for KSystemClipboard::changed signals if:
1. the received mode is QClipboard::Clipboard
2. the new content and its type are different from the current ones.
The problem here is that, before locking the screen, current content is not empty. As of condition #2, a network packet with the empty text will be sent, which clears the current clipboard selection in GBoard but the contents stay the same. Upon re-sync in unlock, a packet will be sent again due to #2.
This commit aims to fix this by ignoring empty text updates since from the end-user it unnecessarily clears the current clipboard selection and results in many "Copied to clipboard" toasts.
The "Add Command" dialog in the settings for the Run Command plugin
looks rather broken at the moment, as the size is not explicitly set and
the default value ends up much smaller than the contents. It uses
QQC2.Dialog, even though the plugin makes heavy use of Kirigami. Using
Kirigami.dialog here would solve the sizing issue, and generally lead to
a more consistent interface.
This change makes the plugin use Kirigami.Dialog instead of QQC2.
BUG: 487438
New OpenSSH versions don't ship them, causing an error:
Bad key types '+ssh-dss,ssh-rsa'
We will add compatibility with newer keys on the Android side soon, as
part of this year's GSOC project.
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.
