Summary:
There is currently an issue where the device doesn't send the correct IP address for sshfs when a VPN is present.
Instead of asking the device to find and send its address, we can store it from when the device link is created then reuse it.
Test Plan:
All unit tests pass.
In these different situations:
- without a VPN
- with a VPN running
- with a VPN started then stopped (the tun interface might still be there)
Try to remotely browse the device. It should work in all cases.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, sredman
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D6730
Summary:
The use of Q_FOREACH is advised against (https://doc.qt.io/qt-5/qtglobal.html#Q_FOREACH) since Qt 5.7 and will eventually be removed from Qt.
I replaced all occurrences with the range-for loop introduced in C++11 (except for the one in daemon.cpp in deviceIdByName which might have a bug / typo in it).
I added const to the container or casted it with qAsConst when appropriate to avoid unnecessary copies.
(This is my first submission. I did all the unit tests, and they all passed but I don't know how to show it here.)
Reviewers: #kde_connect, nicolasfella, apol
Reviewed By: #kde_connect, nicolasfella, apol
Subscribers: albertvaka, apol, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D6724
If we're ignoring an ssl issue, at least show it.
On connected show whether the socket is valid, otherwise we get remote
devices disconnected without any message. (In this case HostNameMismatch)
Also fixes a typo
CCBUG: 381542
KDE Connect runs, and the bluetooth service gets published in the SDP
(service discovery protocol), which other devices use to determine what
services are available.
The getPairedDevices() method in the link provider class uses D-Bus to get
the list of paired devices, since Qt doesn't have a method giving that
information. As a result, that part of the code only works on Linux.
REVIEW: 122174
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
If both devices are in "discovery mode" (ie: both want to keep links
established) and the last one to create the link goes out of discovery
mode, it will close the link when it shouldn't (because the other end still
was "using" it to display it to the user).
Introduces a big fat buffer :(
Actually test the trasfers :)
Takes QSslSocket causistic into account, for some reason QNAM refuses to
mark as finished when the QSslSocket (through QIODevice) closes.
It would be good to look into dropping the QBuffer, doing so with the test
in place will help.
Makes it possible to specify the different properties sent at once,
rather than one by one as we used to do.
Also port whenever possible to the initializer-list syntax.
REVIEW: 128269
