QString or QStringList then it blows up with:
/home/rob/kde/src/kdeconnect-kde/kcm/kcm.cpp: In constructor ‘KdeConnectKcm::KdeConnectKcm(QObject*, const KPluginMetaData&, const QVariantList&)’:
/home/rob/kde/src/kdeconnect-kde/kcm/kcm.cpp:82:17: error: ‘class DaemonDbusInterface’ has no member named ‘linkProviders’
82 | daemon->linkProviders(),
even though the signatures are correct etc. No idea, I'll have
to fix this ultimately but I'll workaround it for now
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;
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
Now that devices can potentially be connected via both network and bluetooth simultaneously we should prioritise connections over the highest performing link (probably wifi/network). To this end the
m_deviceLinks are now sorted based on priority with the fastest links first; this means that when Device::sendPacket is scheduling to send a packet, it should always use the fastest link first.
We operate on a QSharedData object and thus can trivially make a copy. We generally don't use use const refs as return values in KDE APIs unless there is a compelling reason to do so
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.
In theory we support Qt 5.6 (because of SailfishOS) but in practice we are not checking that in the CI so probably we broke the compatibility long ago. Also, I don't think anyone is using this code in SailfishOS, so we can greatly simplify the code by requiring Qt 5.15 or later.
Add the necessary bits for XDG activation to work
Move the code for launching the settings from the daemon to the respective processes so that we don't need to pass activation tokens over another process boundary
Better patch to replace !218.
- Auto and quick detection of previous D-Bus instance;
- Remove private D-Bus compile definition, only use it on macOS without an existing D-Bus instance;
- Safe reboot after crashes because the indicator is not relating on the kdeconnectd to run a D-Bus session;
- Safe exit after clicking on `Quit` in the systray.
More details in commit logs:
Only enable private D-Bus on macOS because the other platforms do not
need them.
The app should be able to easily detect the session bus from the env
DBUS_LAUNCHD_SESSION_BUS_SOCKET from launchd through launchctl.
Because https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-sysdeps-unix.c#L4392
shows that it is the only probing method on macOS with launchd.
The D-Bus session bus can be easily found from launchd/launchctl
with DBUS_LAUNCHD_SESSION_BUS_SOCKET env. It can be an external one
(installed from HomeBrew) or an internal one (launched by a previous
instance followed by a crash).
The indicator helper on macOS can now automatically detect whether we can use a potentially
(with launchd/launchctl env set, or KDE Connect macOS
private_bus_address set) existed and usable session bus.
If previous bus is usable, just try to launch the kdeconnectd with us.
Otherwise, launch a private D-Bus daemon, export the launchd/launchctl
env, and run a kdeconnectd instance.
Everything works better and quicker now :)
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
pluginloadtest and sendfiletest are crashing. This patch fixes that by allowing Daemon::init() to be called from TestDaemon
## Test Plan
### Before:
Both tests are crashing because it is not able to find any devices. It is not able to find any devices because the LanLinkProvider is not being added because Daemon::init() is not being called.
### After:
pluginloadtest and sendfiletest pass
Summary:
Below is a lost of the commits, but, in summary
Port the build system for Sailfish, which means selectively building only the bits we need/can, and only against the KF5 libs that are available.
Allow to build on Qt 5.6
Switch from knotification to nemo notification (not complete!)
Add a very simple example sailfish app.
Note, there is still much missing functionality. Notifications dont work, pairing sort of works but not really, but when it is paired you can send a ping to the desktop client
Dont build kio for Sailfish
Port core build system
Port daemon buld system
Require CoreAddons on Sailfish
Port plugins build for sailfish and include the ping plugin for now
Final build changes for sailfish.
Disable tests and other not needed parts
Add includes for QCA
Fix build errors on sailfish
Get core/ to build on sailfish
Get interfaces/ to build on sailfish
Build daemon on sailfish
On sailfish, dont install the kcm file
Start port plugin to sailfish
Fixup installed files
Add sfos app
Hack declarative plugin to give a public interface
Build sfos app
Compile declarativeplugin into the sfos app for now
Redefine qAsConst for qt 5.6
Packaging fixes
Use official icon
Package .desktop
Reviewers: #kde_connect, apol, nicolasfella, albertvaka
Reviewed By: #kde_connect, apol, nicolasfella, albertvaka
Subscribers: kdeconnect, andyholmes, albertvaka, kossebau, mtijink, vonreth, apol, #kde_connect, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D10703
