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
apol |
KDE Connect |
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
Message History:
New Message:
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
QML suggestions are welcome! I am not proud of everything here, but I spent a long time trying everything and what you see is the best way I found which works
When I open a long conversation I initially see one message. Scrolling has no effect at all. When dragging I see a couple of messages appearing and immediately disappearing. Still only one message stays. Scrolling still has no effect. I can show new messages by dragging the single message. If I show about half of the new messages scrolling still has no effect. When I drag long enough to trigger the second reload scrolling works as I would expect it.
Yes. The issue is the backend only has one message loaded from the phone. When the view first loads it requests the first 10 which causes the backend to request from the phone. Once they're in cache this isn't a problem (try opening the same conversation twice after a slight delay)
I agree this is kind of ugly but I don't know an easy way to fix it. One thought is to make ConversationsDbusInterface::requestConversation synchronous and block until it is able to serve the request. This would be good for several reasons... For one thing, it would enable having multiple conversation views open at the same time!
Scrolling has no effect at all.
Do you mean with the mouse wheel, or with a touchpad? It works with a mouse wheel (and with dragging), but I only just tested a touchpad and that doesn't seem to work. It works after there is more than one message showing. Maybe the solution is to fix the only-one-message problem.
When dragging I see a couple of messages appearing and immediately disappearing. Still only one message stays. Scrolling still has no effect. I can show new messages by dragging the single message. If I show about half of the new messages scrolling still has no effect. When I drag long enough to trigger the second reload scrolling works as I would expect it.
Could you try disabling the places where I mess with the highlight animation? These are lines 96 and 106 of ConversationDisplay.qml. This won't fix the scrolling, but it might fix the invisible message (of course, you'll get an ugly animation instead...)
Do you mean with the mouse wheel, or with a touchpad? It works with a mouse wheel (and with dragging), but I only just tested a touchpad and that doesn't seem to work. It works after there is more than one message showing. Maybe the solution is to fix the only-one-message problem.
Neither mouse nor touchpad work for me
Making it blocking sound like it could cause issues when a device is not reachable. Have you actually tested this?
When opening the conversation a bunch (10) messages are requested. The problem is that once they arrive the view isn't updated, isn't it?
Making it blocking sound like it could cause issues when a device is not reachable.
When a device is unreachable, we have a whole different pile of problems. I will work on solving those "soon"... Basically as soon as we can get this patch to work for you!
Have you actually tested this?
When opening the conversation a bunch (10) messages are requested. The problem is that once they arrive the view isn't updated, isn't it?
That is a different way of looking at the problem. Maybe I am looking at it the wrong way, but my thought is it is very hard for the view to communicate to the dbus interface:
a) Which conversations are currently being looked at (thus which conversations it wants to see updates for)
b) Which messages of those conversations it actually wants
My opinion is that the dbus interface should create the appearance of containing all messages, even if that is actually an illusion and it has to call back to Android. Thus, it should return the requested messages (if they exist) directly (synchronously) rather than just dropping the initial request while it scrambles around to find the requested messages.
It works quite well.
When opening a conversation there should be enough messages to fill the screen (if available). In my case this is about 20 single-line messages, so the current 10 are not enough.
The problem of scrolling having no effect seems to appear when there are not enough messages to fill the screen and thus when there is no scrollbar.
Looking good!
plugins/sms/conversationsdbusinterface.cpp | ||
---|---|---|
69 ↗ | (On Diff #44339) | Use m_conversations.value(conversationID). Otherwise, if conversationId doesn't exist, it will create the entry and leave it empty. |
76 ↗ | (On Diff #44339) | messagesList.length() <= end |
plugins/sms/smsplugin.cpp | ||
80 | Why this change? | |
85 | Definitely not. | |
plugins/sms/smsplugin.h | ||
113 ↗ | (On Diff #44339) | Would it be very hard to just do it now? |
There is something really strange going on here. It looks like I accidentally uploaded an older patch 😬
This one is actually incompatible with D16475 😬 . Yet I suppose it was working for you guys...
I will upload the version I meant to upload in a second. This time I will double-check my patch.
plugins/sms/conversationsdbusinterface.cpp | ||
---|---|---|
69 ↗ | (On Diff #44339) | This is actually fixed in D16475 |
plugins/sms/smsplugin.cpp | ||
80 | Because some places we had ints (specifically, this is how Android stores the value) and some places we had strings. It was a bit of a pain for me to remember which went where, so I declared everything should be int. Declaring everything should be string would be just as valid | |
plugins/sms/smsplugin.h | ||
113 ↗ | (On Diff #44339) | I am actually working on this right now. I hope it is not too difficult |