This started out as me looking for input on how to proceed but in the process of writing it I believe I have come to a conclusion on how to proceed. But if you have any questions or comments, please don’t hesitate.
I’m trying to work out more of the thread stuff, but I’ve run into an interesting dilemma.
I recently build Threads which is a collection of conversations whose type is thread. This collection is exposed on every conversation via the Conversation:threads property.
My original thought was to have the ConversationManager monitor the Threads::added and Threads::removed signals and then add/remove them to/from the ConversationManager. But that causes some issues.
For something like Zulip, this makes sense to at least the active threads (topics) as they are long lived and make sense to display side by side other conversations.
For others, like Slack and Discord, threads might only only have a single reply and don’t typically get archived, so automatically displaying them next to other conversations would quickly clutter the UI.
After these realizations, it seems pretty obvious that we just let the protocol decide to add the conversation to the manager or not and that should take care of most of the issues.
This gets complicated by the manage though as threads are just normal conversations so they need to be loaded like all the other conversations. This means we’ll need a flag to determine if the threads should be added to the main collection of the manager or the threads collection on the parent conversation.
We could add a property for this, but the back end could add an additional property of where the conversation belongs.
Although a property might make sense for stuff like the IRCv3 status window and eventually the debug conversation when it gets ported to a conversation. This way those conversations could be stored only in the manager and have their visibility toggled. But this would mean the UI’s would have to filter the main list of conversations so we’ll leave this to the back ends for now.
So ultimately what it’s come down to is that protocols are responsible for adding threads to the main conversation collection and the conversation manager back ends will need to keep track of whether or not a thread gets loaded into the main list or the thread collection for it’s parent conversation.