Copies over David's implementation in Klipper and integrates it in the
plugin. To do so it splits the ClipboardListener class into 2
subclasses: one that uses QClipboard and the other that uses the
DataControl classes.
BUG: 359747
Ensures the reply window is raised using Qt::WindowActive state. This
properly raises the window reliably (including from plasmoid, which
didn't work at all before) and focuses the reply textbox.
This means that they are not deleted automatically on timeout and thus can be interacted with from Plasma's history.
The KNotification is parented to the Notification so it gets deleted when the notification is dismissed from the phone or the Plasmoid.
timeToEmpty in UPower is unreliable, e.g. it's always 0 on the PinePhone.
Instead warn when the percentage drops below 15%. That's how it is for Android anyway.
* 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.
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.
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
Without it, the build may fail with:
fatal error: kcmutils_version.h: No such file or directory
35 | #include <kcmutils_version.h>
| ^~~~~~~~~~~~~~~~~~~~
KScreenLocker does not allow unlocking the screen via the screensaver interface by design (https://bugs.kde.org/show_bug.cgi?id=425616).
However it allows to do it via the logind interface, so let's use that here.
While at it also refactor the code and properly track and send the state, so the other device can show an appropriate label.
Instead of having the DBus stuff in a separate class expose the plugin class itself like we do for the other plugins.
Replace the method-based API with properties.
Change the path to <device>/battery for consistency with other plugins
We don't have a custom destructor and the copy ctor/assignment operator don't do anything special, so the default one will do the right thing.
This is in accordance with the rule of zero (https://cpppatterns.com/patterns/rule-of-zero.html)
While mostly theoretical it makes for a more expressive API since it communicates that it is a list instead of a single value. It also allows to get rid of some conversion code.
This is also preparation work for potentially using the custom type capabilities that QtDBus offers.
This automatizes the generation of logging categories so a
kdeconnect-kde.categories is generated and installed to
/usr/share/qlogging-categories5/ so kdebugsettings can use it.
Also, sets the default logging level to Warning. So now the logs
of users won't be filled with debug messages but they can
modify the configuration easily with kdebugsettings.
This was removed to drop the notificationsplugin's "No icon" hack, but de facto all notifications have icons.
This makes sure that the KDE Connect entry in the notifications KCM has an icon
playerctld (https://github.com/altdesktop/playerctl/issues/161) is a proxy daemon for the currently active player by playerctl, which facilitates managing mpris players, forwarding requests to the currently active/last active player, and sorting out troubles with selecting the correct player manually.
Unfortunately, it also creates an annoying issue with kdeconnect: when playing media on the phone, kdeconnect publishes the state to the computer through the mprisremote plugin - then, playerctld picks it up as active player, and registers its own mpris media player. As a result, the mpriscontrol plugin sees this as a running media player, and in turn, publishes the state back to the phone, essentially creating another media session on the phone, resulting in two notifications. As playerctld is _always_ only a proxy to another media player (or kdeconnect), it can safely be ignored, just like kdeconnect itself already is. This commit adds an if check doing exactly that.
## Summary
The core idea is as follows:
1. When a Link loads the BatteryPlugin, we query Solid for a list of batteries.
1. If the list is empty, we print a warning message and return quickly
2. Otherwise, we connect *two signals* to every object in that list
2. We send out a single new NetworkPacket as soon as we've processed that list
3. When either of those two signals emits, we send another new NetworkPacket
### Multi-battery Support
BUG: 357193
To handle devices with multiple batteries (requested in that bug), we average
together the battery percentages. This also includes a new field in the packet for
'number of batteries' called `batteryQuantity`. For backwards compatibility, we can
assume it has a default value of one.
This should ensure we support
- devices with no batteries at all (like many desktop machines)
- devices with hot-pluggable batteries (like those laptops with detachable screens)
### Concerns
Note that the implementation isn't perfect.
We'll need some new localizable text to make it clear that we now support sending
battery status information.
Then there's a rather significant question: maybe we should have two battery plugins
on each client, like we do for the `findmyphone`/`findthisdevice` plugins?
## Test Plan
We need to ensure that other clients (including those using the Android codebase)
will respond correctly. The main things to look at are
1. are these new packets sent when the plugin is enabled, and not sent when it's disabled?
2. is the charge percentage accurate?
3. is the charge state (charging, discharging, or full) accurate?
and
4. do we see the correct number of warnings for low-battery?
## Summary
Start a conversation with contacts having no previous conversation with.
It is currently only possible to use the messaging app to send a message to a conversation which already exists.
This patch implements this feature by integrating all contacts having no prior conversation with the recent conversations in the recent conversation list and at the bottom in a sorted manner, something like this,
The contacts are stored in the recent conversation list model as a conversation but with INVALID conversation ID and INVALID conversation DATE.
## Testing
Testing just needs kdeconnect daemon to be recompiled and executed.
Updated plugins/share/shareplugin.cpp:
- KFileUtils::suggestName() is a drop-in replacement as of 5.64,
just moved to another library
Updated plugins/findthisdevice/findthisdevice_config.cpp:
- KCModule::markAsChanged() is likewise as of 5.64
Signed-off-by: Peter J. Mello <admin@petermello.net>
Summary:
The current behavior in plasma-workspace's mediacontroller is to get the
title and the album info from the URL contained in the MPRIS metadata,
if it is dealing with a local file and missing title and artist. This
commit aligns the behavior to the one mediacontroller has.
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D26097
This may need to be reworked at some point for more advanced usecases (multiple apps listening to SMS, variable-length message requests, etc.) but it's fine for now
BUG 410095
Summary: Added a timestamp to track clipboard changes, so when a new device connects it will sync the most recently updated clipboard to both devices.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D22584
Summary: It is functional on the desktop as well and provides a place for controls for desktop to desktop features (e.g. MprisRemote, LockPlugin) and controls for non-Plasma desktops (e.g. Remotekeyboard, not yet implemented)
Test Plan: Builds
Reviewers: #kde_connect, apol, sredman
Reviewed By: apol
Subscribers: piggz, apol, sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15399
## Summary
Upgrade the SMS App to handle multitarget addresses in the "addresses" field of a message and drop usage of the "address" field
Also note that this has all the commits from https://invent.kde.org/kde/kdeconnect-kde/merge_requests/97, but I will rebase those away once that patch is landed
Bonus: Image composition for multitarget conversations
## Test Plan
- Apply Android-side patch https://invent.kde.org/kde/kdeconnect-android/merge_requests/80
- Launch SMS App
- Notice that you can see all the recipients of multitarget messages. (Replying still not supported, but might get implemented as part of fixing replying to single-target messages)
## Summary
Desktop companion to https://invent.kde.org/kde/kdeconnect-android/merge_requests/78
Give desktop SMS app a basic understanding of the MMSes coming from Android:
- Show a fake body if we get an attachment we can't display (for now, any attachment)
- Display a fake contact header for multi-target messages since Android does not yet export multi-target address information
- Disable attempting to reply to multi-target messages
BUG: 398889
## Test Plan
### Before:
MMS messages were silently dropped, meaning:
- Group MMS conversations were not visible
- Single-target conversations with the most-recent message an MMS were not visible
### After:
- Install https://invent.kde.org/kde/kdeconnect-android/merge_requests/78
- Multi-target conversations are displayed (kind of ugly, since they have no contact information
- Single-target conversations which end with an MMS are displayed
- Plain-text MMS is displayed nicely
- MMS attachments don't show
- MMS which are only an attachment with no body are displayed with a dummy body
Summary: This plugin sends a request for a photo to the connected device. The device then sends the photo back, currently via the SharePlugin.
Test Plan:
kdeconnect-cli --photo
Check for photo in Downlaods folder
Reviewers: #kde_connect, broulik, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: sredman, albertvaka, apol, ngraham, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D18140
Summary:
A user may have Kate installed but another editor set as default for text/plain. Respect that.
Also add .txt extension to the temp file name to make mime-type detection easier.
BUG: 399174
Test Plan:
Set default text editor to Kate -> Text opens in Kate
Set default text editor to Atom -> Text opens in Atom
Reviewers: #kde_connect, broulik, apol
Reviewed By: #kde_connect, broulik, apol
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15813
Summary:
When Android sends a list of possible actions add them to the notification. When the action is triggered send a package containing the id and the action back
CCBUG: 366475
Test Plan: Send dummy notification, see the actions, trigger it, look for received package on Android
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, kdeconnect, broulik, mtijink, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D12293
Summary:
Use QPointer for KNotification
Use ready signal for signalling updates
BUG: 400010
Test Plan: Spawned some notifications
Reviewers: #kde_connect, broulik, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D18354
Summary: This patch fixes T10184 and stops the SMS app from crashing when a conversation is selected but no devices are connected. It also allows the SMS app to access the cached messages in the ConversationsDbusInterface so the app is still slightly useful even when the device is disconnected.
Test Plan:
- Open sms app
- Open a few conversations
- Disconnect phone (Force close app?)
- Re-open a conversation which was previously opened
- Verify that the messages appear. It is possible to scroll up to view any older cached messages too!
- Open a conversation which was not opened previously
- Verify that a single messages is shown (since this was the only one in cache, from populating the list of all conversations)
- Verify that attempting to scroll this conversation does nothing, but also does not crash the app
Note: Opening the app with no phone connected will cause it to lose its handle on the deviceId, so it can't spawn a new Dbus interface, so it will remain blank and empty. Solving that is a project for another day.
Reviewers: #kde_connect
Reviewed By: #kde_connect
Subscribers: apol, nicolasfella, kdeconnect
Tags: #kde_connect
Maniphest Tasks: T10184
Differential Revision: https://phabricator.kde.org/D17634
Summary:
After using the ConversationsDbusInterface for a little while, there can be significant (MBs) memory usage of cached messages. The QDBusAbstractAdaptor does not like to be manually deleted, but it looks like it is safe to do so after constructing a new one
This contradicts the comment in the BatteryPlugin and the BatteryDbusInterface, which says deletelater() is not safe. Has Qt been updated since then?
Test Plan:
- Run daemon
- Hopefully experience no crashes after many phone reconnects
Reviewers: #kde_connect, apol, albertvaka
Reviewed By: #kde_connect, apol, albertvaka
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16553
Summary: There is no reason to set UDSEntry::UDS_NAME to "folder" and then override it with UDSEntry::UDS_DISPLAY_NAME
Test Plan:
Apply patch, click android device in dolphin's Devices list
Verify phones sdcards are listed as befor
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D18223
Summary: Added primitive support for the mpriscontrol plugin on Windows by simulating VK_MEDIA key presses. I took a look into `ISystemMediaTransportControls`, but there doesn't seem to query it since it's per app. Leaving simulating key presses our only option for now. Completes T10000
Reviewers: kdeconnect, #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka
Tags: #kde_connect, #windows
Maniphest Tasks: T10000
Differential Revision: https://phabricator.kde.org/D17702
Previously, we would have a thread which was never woken. Now we wake the thread and it does its thing, even though we were not able to do anything about its request
Resolves https://bugs.kde.org/show_bug.cgi?id=400488
Summary:
Scroll up to show older messages
Newly received messages will not force the view to the bottom unless the new message is being added "very close" to the visible area
Test Plan:
Message History:
- Open conversation
- Scroll/Drag up to load older messages
New Message:
- Open conversation
- Scroll to bottom
- Verify that a newly-received or newly-sent message is added to the GUI
- Scroll up
- Verify that sending/receiving a message does not disturb the view
- Scroll back to verify that the new message was indeed added to the list
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, nicolasfella, kdeconnect
Tags: #kde_connect
Maniphest Tasks: T9556
Differential Revision: https://phabricator.kde.org/D15979
Summary:
The most serious change from this patch is to move the asynchronous replying to a request from the app for more messages to a newly-spawned, self-destructing thread. Within that thread, we block until the remote device replies with the requested messages.
All gotten messages are cached in the ConversationDbusInterface, so all future requests are fast and don't hit the remote device.
Test Plan: After applying this diff, the messaging app should show 10 messages every time it is opened
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16475
Summary: Change ThreadID to long
Test Plan:
Messages should send and receive as before. Additionally, if your device has assigned extremely large ThreadIDs, the SMS plugin should no longer crash.
This patch corresponds to the Android-side revision D17517
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17516
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: When a file share is received the share plugin does not detect that an empty file is being shared
Test Plan:
Send an empty file from android
The empty file should be created
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17175
Summary: I've added Windows support to the systemvolume plugin.
Test Plan: Move the volume sliders in the Android app
Reviewers: kdeconnect, #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect, #windows
Maniphest Tasks: T10000
Differential Revision: https://phabricator.kde.org/D16936
Summary:
Add "event" field to ConversationMessage
Update packet type with proper field names and commenting
Future "proof" SmsPlugin against new event types
Test Plan:
- Install the corresponding Android-side patch D16600
- Verify that it is possible to synchronize messages the same as it was before
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16599
Summary:
When the music is resumed during the call it was paused again when the call ends
Bug: 400787
Test Plan: Get called, resume music during call, check state after call
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16809
Summary:
Added windows support to the runcommand plugin
Completes T10001
Test Plan:
1. Run a command
2. Run the command
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, shivanshukantprasad, apol, nicolasfella, kdeconnect, #kde_connect
Tags: #kde_connect, #windows
Differential Revision: https://phabricator.kde.org/D16746
Summary:
Add openFile to Share Plugin and extend handler to open local file urls
Future extension: Modify the desktop file to allow Open with > Open on connected device
Depends on D16605
Test Plan: Apply Android patch. Use kdeconnect-handler file:///somefile. Check phone for reaction
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: sredman, kdeconnect
Tags: #kde_connect
Maniphest Tasks: T8637
Differential Revision: https://phabricator.kde.org/D15294
Summary: This allows you to send a text string from qml, this can be used in the plasmoid and qml app.
Reviewers: nicolasfella
Reviewed By: nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16640
Summary:
Some plugins were copy/pasted from a template and forgot to change their include guards. Since plugin header files are never cross-referenced, this was not a serious issue, but it looks nicer to be correct
NotificationListener.h did not have an include guard. As before, this is not a problem currently, but it's best to have it fixed
Test Plan: Project should build, compile, and run as normal
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16437
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:
When a new message is delivered, the conversation list should update by changing the preview text and re-sorting the conversations
Bonus bug discovered and fixed: previously, when the conversations list was being populated, it made a request for the first message in every conversation. This would be fine if the conversationdbusinterface pulled from local cache. However, this actually triggers a request to the phone for *every* conversation.
This should be handled differently in conversationdbusinterface's requestConversation as well, but that's a project for a later day (TODO comments added)
Test Plan:
- Launch SMS app
- Verify conversations list appears
- Verify lack of massive stream of debug output indicating lots of messages for the wrong conversation are being received
- Verify that opening a particular conversation shows the messages after a short delay while the backend fetches the content from the phone
- Verify that receiving a new message into an existing conversation updates the conversation list
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: nicolasfella, apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15608
Summary: Braces to start a method are on a newline, braces to begin an in-method block are on the same line
Test Plan: Pure source code cosmetic changes. Hopefully no functionality has changed!
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: apol, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15978
Summary:
Update sms app model to use new conversationUpdated signal
Filter incoming messages which belong to a different conversation than the one currently being viewed
See Android-side diff D15360 which adds support for sending live updates when a new message is sent or received
Test Plan:
This patch relies on D15360 for Android-side support
- Positive case:
- Open a conversation in the SMS app
- Receive a new message into that conversation (text yourself?)
- Verify that the new message appears at the bottom of the appropriate conversation
- Negative case:
- Open a conversation in the SMS app
- Receive a new message into a different conversation (text yourself?)
- Verify that the new message does *not* appear in the open conversation
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15409
Summary:
Drop support for creating notifications from the SMS plugin. The old usecase is better handled by the notifications plugin reply box anyway
Rename packets defined in SMS plugin from PACKET_TYPE_TELEPHONY_* to PACKET_TYPE_SMS_*
Update TELEPHONY plugin packet description to point to SMS plugin
Define TELEPHONY_REQUEST_MUTE packet to replace old TELEPHONY_REQUEST with mute event field
Please see Android-side patch here: D15544
Test Plan:
I see four test cases, based on the version of the app being used, where "old" means any version built with sources not containing this revision and "new" means any version built with sources using this revision:
- New Android vs. New Desktop
- Supported and works for me
- New Android vs. Old Desktop
- Supported and works for me
- Old Android vs. New Desktop
- Not supported - Download a new app from the Play store or F-Droid
- Old Android vs. Old Desktop
- If this is broken, it is not my fault :)
In the supported use cases:
- Test SMS reply
- Receive SMS (or MMS!) message
- Verify that the //notification// plugin forwards a replyable notification and that replying works
- Test incoming call ringer mute
- Enable ringer volume (not vibrate)
- Receive phone call
- Verify a desktop notification with a Mute button appears
- Verify that clicking the mute button causes the phone to stop making the ringer noise (vibration not affected)
Reviewers: #kde_connect, albertvaka, nicolasfella
Reviewed By: #kde_connect, albertvaka, nicolasfella
Subscribers: nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15543
Summary:
Telephony and SMS handling are quite distinct so they should be in separate plugins for better maintainability, given that @sredman has big plans with SMS.
This diff should be fully backwards compatible, but whether we really want to do that is up to discussion
Test Plan: Only supeficially tested. Receive an SMS (old way), Notification is shown
Reviewers: #kde_connect, sredman
Reviewed By: sredman
Subscribers: albertvaka, apol, sredman, kdeconnect, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D13594
Summary: Previously, incoming messages were appened to a QList. This list was accidentally sorted because that's how Android returned them, but new messages were appended to the wrong end of the list. This patch specifically and intentionally sorts messages so new ones become visible
Test Plan:
- Open SMS GUI, verify that the most-recent messages are shown
- Either send or recieve an SMS
- Wait about 5s (I do not know why this is necessary. Probably some Android weirdness)
- De-select the current conversation, then re-select it
- TODO: Make the app automatically respond to new messages
- The newly sent or recieved message should be shown in the most-recent position
Reviewers: apol
Reviewed By: apol
Subscribers: apol, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15108