Feature added. Firstly we check if the searched message is already displayed and if yes simply jump
to it, if not then we are loading new 20 messages in the past using cursor and check if the
searched message's id is among those received messages. We do that in a loop till we find the
message we are searching for.
Fixes: #3005
This bug is happening if you have more than one private chat in the contacts column. How many chats
you have that many same notifications you will get. That's happening cause connection is made
between chatsModel.messageView and ChatsMessages component for each private chat, and for each of
them ChatsMessages component is maintained in StackLayout component what means all of them are
exist but only selected instance is visible. When new messageNotificationPushed signal is emitted
each qml component triggers its slot (regardless component is not currently visible it exists in
the background, it's not deleted) and that's why we see more than one OS' notification bubble for
the same notification.
That is fixed moving slot from ChatMessage component to ChatColumn component.
Fixes: #2551
The issue is happening randomly. I managed to catch it few times and hopefully fix it. Problem was
in leave proc in src/status/chat.nim cause we were sending activeChannelChanged signal from it what
started setting activeChannel to the value of the backToFirstChat variable, and while that process
was in progress setActiveChannelByIndex was called from activeChannel what caused another emit of
activeChannelChanged signal while the previous one was not completed. That caused new setting of
activeChannel with active channel index 0, what caused an app crash.
This is fixed by setting active channel to the first one from the list when we get a signal that
any channel from the list is removed. This way activeChannelChanged is broadcasted to the other
parts correctly.
Fixes: #2825
For an unknown reason, when the `chatLogView` ListView uses
a `verticalLayoutDirection: BottomToTop`, it prevents the application
from successfully rendering during login and crashes.
From debugging this, we know that this only happens when the above
condition applies *and* when a `DelegateModel` is used.
The delegate doesn't even need proper data, it application would still
crash.
We found out that the crash can be avoided when another `ListView` exists
in this component (however it's unclear why).
For now this commit adds such a placeholder `ListView` until it
we know more about what's going on.