Approach to ConversationListBox
Goal of this document is to describe the steps involved in moving from a Textview based widget to a ListBox based widget and to describe to the project what the plan behind the coming PRs and commits will be, also requested by @lovetox.
The document is stored in wiki form to allow discussion and mutual manipulation of the document.
For reference, here's the relevevant discussion from the Gajim MUC (where
erik == @ehuelsmann):
[11:22:39 PM] lovetox: erik, yes refactoring some things before working on the listbox is a good idea [11:23:14 PM] lovetox: its best you write down where you see potential for refactoring and let me look over it [11:23:58 PM] lovetox: so i can tell you into how much of a rabbit hole you are getting your self :) [11:24:48 PM] erik: lovetox: thanks. I've started some initial explorations in that area. Are you asking that I wrote something like a refactoring plan before going into the actual effort? [11:24:49 PM] lovetox: and of course the smaller the PR the faster it gets merged [11:24:56 PM] erik: I think that's fair [11:25:38 PM] erik: Ok. I'll write a bit of a plan and work on small commits along the plan. [11:26:04 PM] lovetox: yeah i think its usefull if you tell me what and where you want to refactor before you start it [11:33:25 PM] erik: I'll need a few days to get more of a grip on the code base.
High level assessment of the existing code base
ConversationTextview is tightly coupled with
HtmlTextview as it highly depends on the fact that the HtmlTextview is an editor: it directly accesses the editor buffer and uses it all over the place.
On the other side,
ChatControlBase depend on
ConversationTextview to display the list of messages, where
HistoryWindow uses some of the api provided by
ConversationTextview to populate the window and does some formatting of its own.
ChatControlBase leaves formatting of messages entirely to
The view performs the following functions:
- Maintaining a mapping of message IDs to text buffer positions
- Maintaining a mapping of 'time' to text buffer positions
- Maintaining a list of corrected messages (by message ID)
- Formatting message lines:
- Adding encryption status
- Adding a timestamp
- Adding the nick of the sender
- Scanning and formatting URLs in message text
- Formatting non-message lines (such as status messages, muc title, etc.)
- Deal with all user-interactions through the registration of various event handlers (popup menu, clicking of URLs, etc.)
HtmlTextview adds a single function to the above: parsing the provided content for
xhtml-im content (and cleaning non-compliant content).
ConversationTextview maintains the following API to achieve the formatting functions:
- (creation and updates of
HtmlTextview.get_buffer()-tags in various places)
For the mappings it maintains the following functions and attributes:
- correct_message [function]
- message_list [attribute]
- last_received_message_id [attribute]
HtmlTextview manages presentation with the following functions:
- display_html (which is also responsible for handling
From the summary above, it seems like
ConversationTextview is all of the model, the view and the controller: it maintains the data to be presented in all its aspects (model), it generates/manages presentation by virtue of the various
print_* methods (view) and it deals with various signals (e.g. user input) which affect presentation as well as other actions such as starting external browsers and all.
This mixture of roles of the
ConversationTextview complicates replacing the presentation of messages with a ListBox from a Textview.