The key is a sha256 of both devices' certificates. Both should generate the
same key, so hey user can check they are pairing against the right device.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
We have a few places that open the KCM, with different arguments.
Centralize the implementation in one place.
This makes it easier to switch to invoking systemsettings5 in the future (once https://invent.kde.org/plasma/systemsettings/-/merge_requests/11 is in).
It also makes sure the relevant device is selected when clicking on a pairing notification.
The function is exposed to DBus for the Plasmoid and potential third-party users.
CCBUG: 425660
This automatizes the generation of logging categories so a
kdeconnect-kde.categories is generated and installed to
/usr/share/qlogging-categories5/ so kdebugsettings can use it.
Also, sets the default logging level to Warning. So now the logs
of users won't be filled with debug messages but they can
modify the configuration easily with kdebugsettings.
Summary:
It's possible that Qt uses the xcb platform by default even in a Wayland
session, so detect such cases and switch to wayland instead to enable
proper support for remote input. Copy code from libkworkspace to not
introduce a dependency.
Test Plan: Started kdeconnectd, uses wayland platform now. Remote input works.
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D22562
Summary:
I noticed this when the daemon crashed and drkonqi refused to submit
a bug report, complaining about a missing bug reporting address.
Additionally, using KAboutData also saves initialising some
properties of QCoreApplication manually.
Test Plan:
sent SIGSEGV to kdeconnect, could've reported the crash
with drkonqi; checked with GammaRay that the properties of
QCoreApplication are initialised.
Reviewers: #kde_connect
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D18542
Summary:
Add a helper function to the daemon interface, which must be subclassed
by the implementations, which creates a simple notification.
For more complex needs, involving interacting with the notification, it
will still be nescessary to use KNotification directly, but this allows
for other future implementations to create a simple notification without
ifdef'ing the code.
Reviewers: kdeconnect, apol
Reviewed By: apol
Subscribers: kdeconnect
Differential Revision: https://phabricator.kde.org/D11104
Summary:
Notifications, QML Text and QLabel accept a HTML subset,
which does not make sense for device names.
BUG: 382243
Test Plan:
Sent a pair request and accepted it, device name
now shown as plain text everywhere.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: #kde_connect
Differential Revision: https://phabricator.kde.org/D6640
Notifications are not persistent, and once gone there is no
way to accept the request. Clicking the notification in the
notification history does nothing in plasma and gnome.
There make them persistent and close them after the pairing timeout,
after which they are no longer useful.
BUG: https://phabricator.kde.org/T5002
At the moment, telepathy integration needs to be compiled within the
daemon. This creates a rather aggressive dependency with Telepathy.
This plugin proposes to move into a plugin, so that if the plugin isn't
present, telepathy becomes out of the picture.
REVIEW: 128149
This sends recieved text messages to any Telepathy client and allows the
user to respond from there.
This should work with both our clients and Empathy.
An account on telepathy is created on activation.
As Telepathy clients expect backends to be always running, this is
started by the daemon to
suppress client errors. The plugin system then talks to the same CM via
use of a singleton accessor.
Based on work by Alexandr Akulich then tidied up and rebased.
