The `QElapsedTimer` was never started. Clean it up somewhat and use a dedicated
250ms timer for reporting transferred bytes periodically (like KIO does it) and
1000ms for calculating speed so it's not as erratic.
Furthermore, report final numbers in `slotResult` rather than complicating
`slotProcessedAmount` for that.
Also, fix typo "send" -> "sent"
* Set magic `destUrl` property to let it know the job destination in case of
multiple files being transferred
* Set a normal "Receiving File(s)" title like we do with "Copying" title
* Set device name and destination path as details
Notifications will now be correctly shown in the KDE Connect plasmoid
and will be synced properly to the phone (i.e. removed if dismissed on
phone). So having notifications history in the Notifications plasmoid
will be redundant and clutter up the history.
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.
IAudioEndpointVolumeCallback::Release was called in callback functions of IMMNotificationClient (through the call to SystemvolumePlugin::sendSinkList), however https://docs.microsoft.com/en-us/windows/win32/api/mmdeviceapi/nn-mmdeviceapi-immnotificationclient points out that:
*To avoid dead locks, the client should never call IMMDeviceEnumerator::RegisterEndpointNotificationCallback or IMMDeviceEnumerator::UnregisterEndpointNotificationCallback in its implementation of IMMNotificationClient methods.
*The client should never release the final reference on an MMDevice API object during an event callback.
So I moved that part of code to another thread so it will successfully run after callback functions work out and call only if endpoint needs to be released (device was removed), so it won't spawn new thread for every generated event
Currently bigscreenplugin emits a signal whose consumption point is not documented in our code.
This patch adds a link to a usecase of this emitted signal.
## Summary
This patch adds an interface to return only a specified window of messages, making loading the conversations history smooth, fast, and enjoyable.
The current implementation of the conversation interface loads all messages every time the conversation is requested. This is might be painfully slow to load in case the conversation is large or if there are a lot of MMS/RCS messages in the conversation (since those are wildly slower to load than SMS)
Requires https://invent.kde.org/kde/kdeconnect-android/merge_requests/122 to enable Android functionality
## Test Plan
- With new Android app and old Desktop app:
- The Android app will notice the missing fields and query for all messages as before.
- With old Android app and new Desktop app:
- The desktop will send fields for the new interface which will not be read and all messages will be returned.
- With new Android app and new Desktop app:
- The new interface is used and returns only a certain number of messages at a time.