tristan/kdeconnect-kde
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

[SMS App] Fix loading more messages

Browse source 
## Summary

For awhile (since at least early last year), it has not been possible to scroll past the first screen of message history. I believe this was due to a version bump in some library, but I was not able to biset it at the time.

This changes how messages are loaded to work again. I like this solution better anyway, because it means one can smoothly scroll back in time without needing to stop every time you reach the top of the history.

BUG: 452946

## Test Plan

### Before:
Scrolling to the top of the kdeconnect-sms history would do nothing. You could only view the first handful of messages in the conversation (whichever messages the app decided to load for you when you first open the conversation).

### After:
Scrolling to the top of the list of messages will cause the app to load more, allowing you to view more history of messages.
This commit is contained in:
Simon Redman 2023-01-22 22:10:46 +00:00
parent 255129680b
commit 5b716dde02
1 changed files with 16 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
smsapp/qml/ConversationDisplay.qml
View file

@ -148,15 +148,26 @@ Kirigami.ScrollablePage
} }
} }
onMovementEnded: { /// As the user scrolls, load more messages when they get to the top.
/// This used to use the onMovementEnded signal, but at some point
/// that signal stopped being emitted reliably when scrolling with
/// the mouse. onContentYChanged is fine for our use, just a bit noisy.
onContentYChanged: {
if (!isInitalized) { if (!isInitalized) {
return return
} }
// Unset the highlightRangeMode if it was set previously
highlightRangeMode = ListView.ApplyRange
// If we have scrolled to the last message currently in the view, request some more // If we have scrolled near to the top, request more messages
if (atYBeginning) { // This threshold of visibleArea.yPosition has been chosen experimentally, but
// should generally be OK because it is defined as a ratio of the content to the visible
// area. As more messages get loaded into our view, this constant will start to be
// less-sane, meaning we will request messages earlier as the user scrolls back in time.
// This is probably a good thing, because it means that scrolling back further and further
// quickly, will be more likely to be smooth.
// Combined with `atYBeginning`, the view scrolls smoothly for me, long past the point where
// the rest of the app is stable, and past the point where Android can fetch messages fast
// enough.
if (visibleArea.yPosition < 0.075 || atYBeginning) {
// "Lock" the view to the message currently at the beginning of the view // "Lock" the view to the message currently at the beginning of the view
// This prevents the view from snapping to the top of the messages we are about to request // This prevents the view from snapping to the top of the messages we are about to request
currentIndex = 0 // Index 0 is the beginning of the view currentIndex = 0 // Index 0 is the beginning of the view