Use a singleton instead of context properties for data handling
Fix passing initial message
Make device menu creation more declarative
Fix initial device handling
Update current device when new instance with initial device is requested
- Move the device combobox to the global drawer
- Move search field and new button to header
- Use Kirigami SearchField instead
- Don't switch focus away from search field when typing
- Give the New button an icon
- Clarify the search field text
- Center messages view loading indicator
- Make send and attach buttons stick to bottom of text area
- Make cursor an I-beam when hovering over text area
- Move send button to the right
- Give proper padding to messages view top
- Move refresh action to global drawer
- Show refresh button directly in loading message where it is most useful
| Before | After |
| ------ | ------ |
|  |  |
|  |  |
|  |  |
cc @teams/usability @teams/vdg
The current implementation seems to have an issue with an undetected binding loop that causes lockup. During investigation I figured that the code was way to complex and brittle for what we need.
This is a cleaner reimplementation. It also replaces the custom Avatar component with the one from Kirigami.
The looks are subject to tweaking of course
## Summary
This patch makes SMS message field scrollable and limits its height to ⅓
of window height (or ⅔ for smaller windows) so messages in conversation
are shown even when writing very long messages.
## Test Plan (and screenshots)
<small>These screenshots are in APNG and WEBP formats. Download them if
your browser does not support this format.</small>
### Before:
Message field height was not limited. Message field could be even higher
than window. That makes first lines of this field and messages in
conversation inaccessible.
### After:
Message field height is limited to ⅓ or ⅔ of window height. When text
content reaches this threshold, scroll bars will show up.
SMS character counter was changing its width (both growing and
shrinking) so it also resized message field (and that caused text
reflow). This patch makes counter width only grow.
Type SMS that is long enough to make SMS character counter wider than
“Send” button. Remove the text (leave there 150 or 60 chars to keep it
visible). Character counter should keep its width.
## Summary
This adds character counter below the “Send” button in SMS conversation. It
uses format XXX/Y where XXX is number of characters that can be added
without splitting the SMS into multiple messages (see article
Concatenated SMS on Wikipedia). Y is number of messages in in current
concatenated SMS. The counter is not visible when insertion of 10 7-bit
or 16-bit (depends on SMS encoding) does not create concatenated SMS.
SMS encoding is automatically guessed. 8-bit encodings are not
supported. If the message contains characters that are not supported by GSM 7-bit
encoding, counter automatically switches to UCS-2.
## Test Plan
Try entering some text that is longer than 150 characters in [GSM 03.38 encoding][1] or 60 characters in UCS-2. Number of remaining characters should be visible below the “Send” button. The character counter should show `0` at exactly 160 or 70 characters. Inserting one character should switch the counter to [Concatenated SMS][2] mode when number of messages is shown.
It should show exactly same number as SMS app in Android.
## Screenshots
These images are in APNG.
[1]: https://en.wikipedia.org/w/index.php?oldid=932080074#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_/_GSM_03.38
[2]: https://en.wikipedia.org/w/index.php?oldid=943185255#Message_size
## 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.
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
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:
Add --message option to kdeconnect-sms to pass a message. The user only needs to choose a recepient and the message will be sent. Useful for integration with 3rd party
apps, e.g. via Purpose
Test Plan:
kdeconnect-sms --message "Hello World", choose chat, message is sent
Click another chat, no message sent
kdeconnect-sms without args, no message sent
Reviewers: #kde_connect, sredman
Reviewed By: #kde_connect, sredman
Subscribers: andyholmes, sredman, apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17292
Summary:
Resolves Bug 401255
Bonus: Disable some very noisy debugging from the SMS app
Test Plan:
- Build KDE Connect with or without Kirigami
- Verify successful build with no complaints about Kirigami
- Build KDE Connect's Messenger:
- Without Kirigami: Verify that CMake warns that Kirigami is not found
- With Kirigami: Verify that app launches successfully
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17572
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:
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:
A scrollbar will show if the entered text fills more than 1/3rd
of the screen, pressing enter will send the message and shift +
enter will add a new line.
Reviewers: #kde_connect, sredman
Reviewed By: #kde_connect, sredman
Subscribers: sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17224
Summary:
Showing the number next to the name is neither pretty nor necessary IMHO.
My Android SMS app displays the number more subtle in an extra line below in gray. I could get behind something similar, but until this is implemented just don't show it
Depends on D16015
Reviewers: #kde_connect, sredman
Reviewed By: #kde_connect, sredman
Subscribers: sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16017
Summary: Don't ask my why this works this way
Test Plan: I see Name: phonenumber for contacts and just phonenumber for non-contacts now
Reviewers: #kde_connect, sredman
Reviewed By: #kde_connect, sredman
Subscribers: sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16015
Summary: Set the currentIndex of the ConversationDisplay to show the newest messages by default, but stay where the user positioned it if viewing older messages
Test Plan:
Launch SMS App:
- Select conversation
- View should show the most recent messages
- Receive new message
- View should scroll to show the new message
- Scroll up to view older messages
- Receive new message
- View should continue to show older messages and not scroll to the bottom
Reviewers: nicolasfella
Reviewed By: nicolasfella
Subscribers: nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15562
Summary: Like every messaging app I know does
Test Plan: Compare message order with phone
Reviewers: #kde_connect, sredman
Reviewed By: #kde_connect, sredman
Subscribers: sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D14638
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
