greyhoof / flist-messenger

A multi-platform desktop client for the F-Chat protocol.
1 stars 0 forks source link

Consider replacing the chat view #13

Open greyhoof opened 1 year ago

greyhoof commented 1 year ago

The chat is currently displayed using QTextBrowser. It is a practical choice but it's limited in a number of ways - not being able to play gifs is one of them.

I'm considering replacing it with something a little more flexible.

Possibly a QScrollArea with a QVBoxLayout which contains a QHBoxLayout with the various parts of a message as individual widgets and handlers for mouse events. It might be less memory efficient than using QTextBrowser. But - we'd be able to directly keep track of and influence all elements that we have in the chat view.

Meaning, instead of loading individual frames into QTextDocument resources for gifs, we can just place a QMovie in the QBoxLayout and let it do it's thing - and we can very easily stop the animation when it's out of view. Cutting off elements after a certain point (maybe the last 200 messages?) would also be easier, I think, by keeping a list of pointers and cutting off the first element when the count reaches 201. That should keep memory usage in check.

The current QTextBrowser (or rather, QTextDocument) implementation could stay and be used to generate HTML log files. I'll probably have to have the command message converted twice, once into an HTML node and once more into a QBoxLayout.

Possible structure of an item (a "row" or "message", so to speak), left to right, within the QVBoxLayout:

Parsing the tags needs some additional work, too. I think the easiest (but maybe not the cleanest) way of doing it would be to give the parser class a "BoxLayoutManager" class that can be called to generate the widgets from the bbcode contents. The Parser would then return a QPair of a string (for QTextBrowser) and a QBoxLayout (for the new view).

greyhoof commented 1 year ago

And all the QHBoxLayouts should probably go in a QListView (as opposed to a QScrollArea) because that only renders whatever is visible on screen.

Not only should this solve potential memory issues (elements out of view simply "don't exist" and only get rendered as they are moved into the view) but I'd also not need a QVBoxLayout since the QListView renders elements vertically anyway.