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.
Summary:
For real usecases of SMS support, we will almost always need access to the message history in some way
Specifically resolve T8338
Incidentally resolve T6651 since Telephony shall no longer create a notification
Test Plan:
Setup:
- Build corresponding Android-side diff (D11698)
- Build this diff
Step 1: Does anything at all work?
- Put a breakpoint in the handleBatchMessages method of the telephony plugin, ideally after constructing a Message object
- Use DBus to poke /modules/kdeconnect/devices/<deviceID>/telephony.requestAllConversations()
- Verify that the constructed Message is one you sent or received and that it is the most recent in the corresponding conversation
Step 2: DBus
- Open the Interface org.kde.kdeconnect.device.conversations of /modules/kdeconnect/devices/<deviceId>
- Poke activeConversations and verify an empty array is returned
- Poke requestAllConversationThreads
- Poke activeConversations and verify that a list of numbers has been returned. These are conversationIds
- Use a conversationId to call getFirstFromConversation
- Verify that the returned Message object is one which you recognize
- Note that if the message is an MMS it will be blank and meaningless. Try a different conversationId. MMS support "coming soon!"
Step 3: SMS App
- Use ccmake (or similar) to set SMSAPP_ENABLE to ON
- Build the project
- Run ./bin/kdeconnect-sms
- Verify that the app shows a list of everyone you have an SMS conversation with (MMS messages are stripped out)
- If you have the Contacts plugin working, verify that most contacts have their name and photo instead of their phone number
Reviewers: #kde_connect, nicolasfella, apol
Reviewed By: #kde_connect, nicolasfella, apol
Subscribers: andyholmes, apol, nicolasfella, #kde_connect
Tags: #kde_connect
Maniphest Tasks: T8338, T6651
Differential Revision: https://phabricator.kde.org/D11854
Summary:
Add a plugin to KDE Connect which supports exporting the Android contacts databases to vcards on the desktop
When the devices are connected, the plugin sends a request for all timestamps and IDs
When a packet with timestamps and IDs is received, it verifies it has vcards for each ID and that the timestamps match and deletes any vcards for IDs which were not reported. It then sends a request for all vcards which were missing or need updating
When a packet with vcards is received they are unconditionally written to disk, possibly overwriting existing vcards
Provides one dbus method: contacts/synchronizeRemoteWithLocal which triggers the request for all timestamps and IDs
BUG: 367999
Test Plan:
Connect the device to the desktop and verify that vcards are created in QStandardPaths::GenericDataLocation / kpeoplevcard". On my system this is ~/.local/share/kpeoplevcard
Create a dummy contact on the device and verify it is synchronized (Currently not automatic, have to disconnect and reconnect or use dbus)
Modify the dummy contact and verify the modifications are synchronized (Currently not automatic, have to disconnect and reconnect or use dbus)
Delete the dummy contact and verify the deletion is synchronized (Currently not automatic, have to disconnect and reconnect or use dbus)
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: mtijink, #kde_connect, apol
Tags: #kde_connect
Maniphest Tasks: T8283
Differential Revision: https://phabricator.kde.org/D9691
