The package will arrive eventually, and dataReceived will be emitted.
Otherwise we just end up calling dataReceived to no end.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
Healthy identity packages shouldn't be that big and we don't want to
allow systems around us to send us ever humongous packages that will
just leave us without any memory.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
## Summary
LanLinkProviderTest fails on Windows. This patch fixes that.
I believe the root cause is that we are using a shared UDP socket to listen for identity broadcasts both in the LanLinkProvider and in the test. Apparently this works on Linux, but on Windows the LanLinkProvider picks up its own identity packet and pairs with itself.
This patch gives a parameter to LanLinkProvider to allow it to listen and broadcast on different ports, then uses that ability in the test to make the test pass on Windows.
## Test Plan
### Before:
lanlinkprovider test fails, first because it can't bind its UDP listener socket, and then because Windows seems to handle shared sockets differently than Linux, so the UDP broadcasts were not reaching the test's listener.
### After:
lanlinkprovider test seems to pass reliably both in my Windows VM and in the CI
Summary:
When android closes the payload socket (cancel share) calling m_socket.close() results
in a recursive call to onError eventually leading to a segmentation violation
Test Plan:
Install D16491, share a large file from desktop to android and cancel the share on Android through
the notification. kdeconnectd crashes almost 100% of the time. (It doesn't crash when it detects
a disconnect in sendNextPacket)
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17628
Summary:
Combine multiple upload jobs for files into a single KCompositeJob so only 1 notification will be shown
Includes changes introduced in D16279
Test Plan:
1. Share of multiple files is performed using 1 composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
Result:
- The files will be transferred using 1 CompositeUploadJob and showing only 1 notification
2. Share of file while another share is already running adds job to existing composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
- Share an additional file with the same Android device
Result:
- The files are all transferred using 1 CompositeUploadJob and showing only 1 notification
- The notification is updated after adding the last file
3. Other packets are transmitted as usual
Setup:
- Setup sharing desktop notification with device
- Share a big file with an Android device
- Generate a desktop notification (eg. sending or receiving an email)
Result:
- Notification packet is send immediately
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, broulik, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17081
Summary:
Show progress when sending a file from the desktop
BUG: 355044
Test Plan:
Complete transfer:
-Right click on a big file in dolphin
-Select Send to xx via KDE Connect
-Open the Notifications widget and verify progress is shown correctly
Stop transfer:
-Right click on a big file in dolphin
-Select Send to xx via KDE Connect
-Open The Notifications widget and press the stop/kill button
-Observe that the file upload is stopped
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: apol, broulik, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16279
Summary:
No need to emit newConnection in Server::incomingConnection because QTcpServer will emit it after incomingConnection returns
QTcpServer also already has a list of pending connections so use that
Test Plan: Send a file from desktop to android and observe that newConnection is only called once
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17009
Summary: Why cast sender() to server when we have m_server
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16760
Summary: This is not a hugely important change. I noticed it while I was working on something else, and it seems like it ought to be this way
Test Plan: Nothing should be noticeably different
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16468
Summary:
Main change is to use libkeepalive to wake up the system to ensure connections stay alive
Other minor changes are:
-Log daemon messages for debugging purposes
-Add way to forece refresh of device list
-Minor spec improvements
The keepalive changes certainly seem to help, not sure if it completely solves the problems
The logging changes are temporary, and I could use them locally, but they only affect sailfish users
Im not sure if the refresh method is correct, but seems to force the daemon to check for devices
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15414
Summary:
It doesn't do much and can be inlined into LanDeviceLink.
TODO: Figure out why sendfiletest fails
Test Plan: Receiving files still works
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D14597
Summary: KDE Connect, now with correct naming!
Test Plan: It still builds.
Reviewers: #kde_connect, apol, nicolasfella
Reviewed By: #kde_connect, apol, nicolasfella
Subscribers: nicolasfella
Differential Revision: https://phabricator.kde.org/D11036
Summary:
Change all member variables to the form m_fooBar because it is the preferred form in Qt (it was half and half between this and mFooBar, and a minority didn't have anything).
Place all references and pointers on the side of the type since it is the majority.
Basically:
- mFoo -> m_foo
- foo -> m_foo (if it is a member variable)
- Type &ref -> Type& ref
- Type *ptr -> Type* ptr
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, nicolasfella, albertvaka
Subscribers: albertvaka, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D7312
We stop using a buffer so it's less memory intensive and allows for larger files to be sent.
With current KIO has CPU usage issues, there's a patch in review that fixes them.
BUGS: 378488
Summary:
QSslSocket is already a QIODevice so just use that.
Should fix the issue of transfering *big* files.
Unfortunately this seems to trigger a bug in KIO and CPU usage goes through the roof, so haven't really been able to test it does actually fix things.
Please don't merge/approve yet
Reviewers: apol, albertvaka, kdeconnect
Subscribers: #kde_connect
Differential Revision: https://phabricator.kde.org/D6039
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
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
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).
