Auto reconfiguration of own certificate:
currently:
if kdeconncectd loads its certificate and its expired or not effective yet
it generates a new certificate
previously:
if kdeconncectd loads its certificate and its expired or not effective yet
it continues having the same certificate
This brings forth an issue: Other devices would refuse to connect to a device with
an expired or non-effective certificate.
Auto-delete of orphan certificates:
currently:
Devices in kdeconnectd's devicelist that have illegal ssl certificates
(expired, not effective yet, empty) get automatically deleted from the
devicelist
previously:
they would just exist forever until the user deletes them
A year does not have 356 days:
currently: int a_year_in_seconds = 365 * 24 * 60 * 60;
previously: int a_year_in_seconds = 356 * 24 * 60 * 60;
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 KDE Connect SMS app currently has the GenericName "SMS" which is the
name of a protocol, not the name for a class of applications, and the
Comment "Text Messaging", which is correct but very short for a field
that is intended to give a short but more exhaustive description of an
application's functions.
This change sets the GenericName To "Text Messaging" and the Comment to
"Read and send SMS messages on connected devices".
The .desktop file for the non-Plasma settings app currently has a
sentence as the GenericName, which is supposed to be the term of a
class of applications, and does not have a Comment field, which is
suitable for descriptions in the form of a sentence.
This change sets the GenericName to "Device Synchronization Settings",
and adds a Domment field that matches the description for the kcm.
The plasmoid currently has the decription "Show notifications from your
devices using KDE Connect. This is wordy and misleading as
the plasmoid does much more than display notifications; it's used to
show the devices and their current state (e.g. battery) and provides
access to some of the broader KDE Connect functionality, such as the
find device function or file sharing.
This change sets the description to "Manage connected devices".
The kcm json currently lists the description as "Connect and sync your
devices". This is hard to distinguish from the KDE Connect application
at a glance, and does not follow the general pattern in kcm descriptions
to use either a configuration-based verb or noun (e.g. configure, edit,
settings).
This change sets the description to "Configure device synchronization".
BUG: 466256
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
Context: https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/600#note_884500
When bluetooth doesn't exist on the machine at all, QTConnectivity
tries to communicate with Bluez via dbus and introduces a 30 odd second
pause. That's not necessarily a problem in concept, however this blocks
the main thread of KDEConnect, which also then blocks the main thread
of Plasma on logon and causes tremendous delays and very broken
behaviour.
For the life of me, I cannot find a way to do "is bluetooth ok" without
QTConnect kicking off the dbus call so I think the only option is to
thread off the startup of the providers so that pauses don't block
the whole process.
I've just tested this here and my logon with bluetooth missing went
from approx 35 seconds down to about 2.
Ready for input/feedback whenever people have time; in my testing at the moment it seems to completely break the behaviour of KDEConnect (i.e. things can't connect), I'm guessing this is something to do with the effect of wrapping everything in the QThread. I'll dig into that next and see if I can figure it out.
BUG: 481870
