Draft
Conversation
Collaborator
|
One thing I want to do in the future is split up chatviewtextprocessor so that we no longer use QTextDocument for all the rendering of ChatItem regardless of the content type. What I'd like to do instead is detect the content type in C++ as the llm generates it. So if we see a code block begins ```cpp then we know it is a code block. Essentially, I envision the chat item containing the raw model response. But also exposing a qabstractlistmodel that splits that raw response into content types. The qml can then display using qml items appropriate for it rather than all the rendering happening in a custom QTextDocument |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I started working on a polymorphic replacement for ChatItem, which differentiates between prompts and responses structurally. The name MessageContent isn't really relevant, that was chosen before it became a full replacement.
Fields that only belong to prompts or responses would no longer have their own roles (columns) in the ChatModel; instead there would be direct access to the ChatItem instance in order to interact with its properties.
I envision this to be less of a struct and more of a self-contained class; everything a ChatItem needs to do (such as being serialized as Datalake JSON) should happen in this cpp file.