Change some optional dependencies from being optional to being mandatory
or being mandatory but behind on-by-default cmake flags. Eg: instead of
only compiling Wayland support if we find the appropriate libraries, we
always require the libraries unless the user specifies WITH_WAYLAND=OFF.
Optional libraries are hard to discover by packagers (since they don't
see an error once we add them) and create lots of possible build flavors
with a different features that can confuse users.
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.
Instead of always doing so on MacOS, do it only when we get a
DatagramTooLargeError. On MacOS, the size is limited only for
broadcast but not for unicast.
Since sockets are buffered `QIODevices` we can use `canReadLine()` to check
if we have a full line, instead of using a custom `SocketLineReader` class
(and the copy-pasted `DeviceLineReader` in the Bluetooth backend).
We can also loop through all the lines instead of queuing calls to `dataReceived`.
And we don't need transactions.
When receiving two files with the same name, the first file might not be
saved to disk already when we have to decide the name for the second if
we do it too early.
BUG: 470078
argument
Previously the BluetoothDeviceLink::certificate() method was returning a
value initialized object which I believe default initializes the object.
However, Clang throws a build error at this because QSslCertificate has
explicit constructors. This change uses one of those constructors and
uses value intialization to default construct/initialize the argument
for it. It fixes the build and hopefully doesn't break anything since
this is a TODO anyways!
BUG: 469428
Signed-off-by: Ali Abdel-Qader <abdelqaderali@protonmail.com>
The main thing it provides over QNetworkAccessManager is integration
with the CookieJar and using kio-http, but since we jsut exchange bytes
from another local device that's not interesting for us
This whole code was no-op: it enumerates network interfaces, enumerates
its IP addresses, but does not change the address of broadcast UDP
packet, sending it only via default route/interface.
Bind the socket to IP addresses of the interfaces to fix the issue.
BUG: 459171
This is the proper way to communicate progress.
It has Plasma show the file name in case of single files
and "n of m files" as before for multiple files.
On FreeBSD 12 or later, a new routing strategy is introduced, which
prevents broadcast using 255.255.255.255.
Thus, we need to explicitly send the broadcast to each network
interfaces.
Here the commit can simply reuse the code for Windows.
Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252596
Detect the MTU on macOS and FreeBSD (which share the network parts of FreeBSD) and adaptively remove the outgoing and incoming capabilities.
The incoming capabilities are usually shorter, fit the size and help initialize the plugin list on the peer. This should fix an empty plugin list when the identity packet is sent by the macOS app.
If the MTU is still too short, both the capabilities need to be removed, which is not likely to happen.
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 :)
