... | ... | @@ -124,37 +124,6 @@ In a chat with @lovetox, the following requirements were mentioned as well: |
|
|
[04:49:23 PM] wurstsalat: File transfers, image previews :)
|
|
|
```
|
|
|
|
|
|
## Design for cleanup of the current state
|
|
|
|
|
|
### Responsibilities of roles
|
|
|
|
|
|
The role of the presentation is to:
|
|
|
* Render chat lines coming in from the server
|
|
|
* Render chat lines going out to the server
|
|
|
* Render status updates from the client, server and chat channel (join/leave/etc)
|
|
|
* Update rendered lines when instructed to do so (corrected messages)
|
|
|
|
|
|
which means that the presentation will also need to:
|
|
|
* map message IDs to buffer regions
|
|
|
* get_end_mark
|
|
|
* get_insert_mark
|
|
|
|
|
|
The role of the model (`ConversationContentModel`) is to:
|
|
|
* add_message [function], to maintain:
|
|
|
* message_list [attribute]
|
|
|
* last_received_message_id [attribute]
|
|
|
* correct_message [function]
|
|
|
|
|
|
The role of the controller (also `ConversationTextview` -- for now, but might need to be GroupChat/PrivateChat/ChatControl instead?) is to:
|
|
|
* respond to user interactions
|
|
|
* (open question: to network interactions as well? alternative: the model gets fed directly from the protocol stream)
|
|
|
|
|
|
### Impact on the existing code base
|
|
|
|
|
|
The various `print_*` functions will to be moved from ConversationTextview to HtmlTextview. This impacts:
|
|
|
* gajim/chat_control:ChatControl.restore_conversation()
|
|
|
* gajim/chat_control_base:ChatControlBase.print_conversation_line()
|
|
|
* (to be continued)
|
|
|
|
|
|
|
|
|
## Design of the end state
|
... | ... | @@ -227,4 +196,66 @@ Also, the content model should provide the view with chat status data: participa |
|
|
* ConversationStatusListBoxrow
|
|
|
* ConversationMessageListBoxrow
|
|
|
|
|
|
Note that this design will allow - when the ContentModel will be connected to a source storing history - browsing back in history, if the content model gets extended to read messages from history upon request. |
|
|
\ No newline at end of file |
|
|
Note that this design will allow - when the ContentModel will be connected to a source storing history - browsing back in history, if the content model gets extended to read messages from history upon request.
|
|
|
|
|
|
### Examples flow of events
|
|
|
|
|
|
Assuming John has joined the John-and-Jane MUC some time ago and he's chatting with Jane (as in: we are well past the initialization/startup phase or "joining process"). Jane responds to John's last message. When John's client receives the message, the following happens:
|
|
|
|
|
|
1. Gajim parses the stream event
|
|
|
1. The `app.events` system calls the event handlers for `muc-gc-message-received`
|
|
|
1. The various instances of MUCs in John's client receive the event
|
|
|
1. The instance of the John-and-Jane MUC recognizes the message as applicable
|
|
|
1. The John-and-Jane MUC instance calls its ConversationContentModel's `add_message()` function
|
|
|
1. The ConvContentModel recognizes this message as being new and adds the function to its history
|
|
|
1. Then the model calls the ConversationView's (either a ConversationTextview or ConversationListBoxview) `add_message()` function with the new message
|
|
|
1. The view renders the message provided at the appropriate position (in this case, the bottom of the message list)
|
|
|
|
|
|
After a bit of chatting, Jane realizes that she made a typo in the message that John received in the last example. She decides to correct it and send it to John. When John's client receives the message, the following happens:
|
|
|
|
|
|
1. Gajim parses the stream event
|
|
|
1. The `app.events` system calls the event handlers for `muc-gc-message-received`
|
|
|
1. The various instances of MUCs in John's client receive the event
|
|
|
1. The instance of the John-and-Jane MUC recognizes the message as applicable
|
|
|
1. The John-and-Jane MUC instance calls its ConversationContentModel's `add_message()` function
|
|
|
1. The ConvContentModel recognizes this message as existing and being corrected
|
|
|
1. The model updates the list of messages with the new message in place of the old one (retaining a copy of teh old one "inside" the new one)
|
|
|
1. Then the model calls the ConversationView's (either a ConversationTextview or ConversationListBoxview) `update_message()` function with the old message's `id` and the corrected message
|
|
|
1. The view renders the message provided at the position where the prior message was rendered, replacing the prior message
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Below is work in progress
|
|
|
|
|
|
## Design for cleanup of the current state
|
|
|
|
|
|
### Responsibilities of roles
|
|
|
|
|
|
The role of the presentation is to:
|
|
|
* Render chat lines coming in from the server
|
|
|
* Render chat lines going out to the server
|
|
|
* Render status updates from the client, server and chat channel (join/leave/etc)
|
|
|
* Update rendered lines when instructed to do so (corrected messages)
|
|
|
|
|
|
which means that the presentation will also need to:
|
|
|
* map message IDs to buffer regions
|
|
|
* get_end_mark
|
|
|
* get_insert_mark
|
|
|
|
|
|
The role of the model (`ConversationContentModel`) is to:
|
|
|
* add_message [function], to maintain:
|
|
|
* message_list [attribute]
|
|
|
* last_received_message_id [attribute]
|
|
|
* correct_message [function]
|
|
|
|
|
|
The role of the controller (also `ConversationTextview` -- for now, but might need to be GroupChat/PrivateChat/ChatControl instead?) is to:
|
|
|
* respond to user interactions
|
|
|
* (open question: to network interactions as well? alternative: the model gets fed directly from the protocol stream)
|
|
|
|
|
|
### Impact on the existing code base
|
|
|
|
|
|
The various `print_*` functions will to be moved from ConversationTextview to HtmlTextview. This impacts:
|
|
|
* gajim/chat_control:ChatControl.restore_conversation()
|
|
|
* gajim/chat_control_base:ChatControlBase.print_conversation_line()
|
|
|
* (to be continued) |