ModelEntryChangeTracker introduced, removed dependency on contact model's onItemChanged
#16758
Conversation
Jenkins Builds
|
…model's onItemChanged signal Closes: #16754
micieslak
force-pushed
the
feat/issue-16754
branch
from
6b1f0e5
to
447a7d0
Compare
| readonly property var myContactsModelConnection: Connections { | ||
| target: root.contactsStore.myContactsModel ?? null | ||
| enabled: d.activeChatType === Constants.chatType.oneToOne | ||
| StatusQUtils.ModelEntryChangeTracker { |
There was a problem hiding this comment.
I'm wondering if we need the ModelEntryChangeTracker. In this case we can use something like this:
property ContactDetails oneToOneChatContact: ContactDetails {
publicKey: d.activeChatId
contactsStore: root.contactsStore
profileStore: root.profileStore
}
Have you found other usages as well?
If this is the only usage, I'd advise against ModelEntryChangeTracker usage. The complete solution should be coming from the ContactDetails component.
There was a problem hiding this comment.
There are two usages right now: Chat/RootStore and ActivityNotificationMessage.
I fully agree it's not a final solution. Right now it's the least invasive method to unblock #16667 which is providing significant simplifications related to contacts models. In the next step we will remove ModelEntryChangeTracker which is only temporary replacement for nim's model onItemChanged signal, releasing dependency on that custom feature of backend's model. The target is to use ContactDetails or join models at early stage to provide all necessary details via models.
Regarding the ContactDetails in this particular context I see also some other problems we should consider:
ContactDetailsdepends onProfileStoreso it would introduce unnecessary dependency to thisRootStoreeven though its totally not needed hereContactDetailsshould not be used in store as it's breaking contract that stores are just a thin layer over backend's functionality
So I'm still assuming it's temporary solution on the way towards further simplifications/cleanup. Just trying to fix everything at once triggers too many changes.
There was a problem hiding this comment.
Totally agree! Glad it's another step forward and not the final solution 😄
ContactDetails dependencies should be simplified as well at some point if we can extract the user profile from the model and we don't need the profileStore anymore.
Ideally it would work only with a model. The purpose of the component is just to provide some default values on top of ModelEntry.
What does the PR do
ModelUtils: optimizeindexOfby moving implementation to C++ModelUtils: expose methodpersistentIndexgiving possibility to obtain persistent index in QMLonItemChanged, unblocking Refactor contacts models to have a single model, remove useless properties and improve updating #16667Closes: #16754
Affected areas
ModelUtils,ActivityNotificationMessagewith subclassesArchitecture compliance
My PR is consistent with this document: Status Desktop Architecture Guide