Feat/all in one - #49
Conversation
Run tool calls that local backends emit as inline text (for models that do not support native tool calling), add optional logging of vtk-mcp tool calls with a persisted setting, and add an agentic-retrieval toggle that skips pre-injected context so the model drives retrieval itself.
Make the prompt client stateless so each conversation (session) owns its messages, then let conversations generate concurrently: each generation is tied to its originating conversation and its result, error, and rendered scene are delivered there rather than to whatever the user is currently viewing. The drawer shows which conversation is generating, the in-pane spinner tracks the visible conversation, and returning to a conversation that is still generating no longer shows a stale result. Each conversation restores its own scene on switch, a new conversation starts idle, titles come from its own first prompt, and the render window is cleared wherever a conversation is reset. Generated code can no longer open a native render window or corrupt the app's window, and the editor remounts per conversation.
Capture stdout and stderr from running generated code (previously only visible in the server terminal) and show them in a per-conversation Console tab beside the transcript. Lines are classified by stream, not text content: stdout is ordinary output regardless of content (a printed class name like vtkErrorCode is not an error), stderr is a warning, and a raised exception is an error. Long lines are truncated and scroll within a width-contained box so large output cannot blow out the layout, and the console is stored on the session so it is per-conversation. The console is now the single record of a run: run errors, generation and config errors, and the data-file resolver's "could not resolve" suggestion (as a warning) all appear there, and the floating alert is removed; the Console tab badge is coloured by the latest run's severity so failures are noticeable from the transcript. When a data-file reference cannot be resolved, offer the closest known names as one-click fixes via a "Fix data file" toolbar menu. The code editor remounts when its contents change (conversation switch or code version) so it never keeps a cursor past the end of shorter content.
The composite editor key (session + code-history length + position) remounted the editor on generate/undo/redo. When that happened while an autocomplete popup was open, trame-code disposed the completion widget mid-flight and threw (null read in dispose); the dropdown flashed and vanished. Key on current_session_id alone, matching the concurrent-conversations behaviour, so the editor only remounts on a conversation switch (when no popup is open).
|
@jlee-kitware changes looks alright, and I can install this in my machine. Can you do a screencast of the changes that this PR does visually to ease reviewing this PR? |
|
It appears that the current flakiness of the app is due to the a missconfiguration of the vtk-mcp, it provides new tools which fails and confuses the llm, ill fix it tomorrow. |
|
vicentebolea
left a comment
There was a problem hiding this comment.
I could finally test this after fixing vtk-mcp
this still happens, It seems to be more prevalent now, I am not sure if that originates from this PR, my other PR is based on this. |
Add MCP tooling, concurrent conversations, and a console panel
Combines three related pieces of work on the trame UI. Supersedes #48 (its MCP-tooling content is included here).
Contents
MCP tool-call support for local and text-emitting backends
Runs tool calls that local backends emit as inline text, for models without native tool-calling. Adds optional logging of vtk-mcp tool calls (persisted setting) and an agentic-retrieval toggle that skips pre-injected context so the model drives retrieval itself.
Concurrent conversations, each owning its own state
Makes the prompt client stateless so each conversation owns its messages, then lets conversations generate concurrently. Each generation is tied to its originating conversation; its result, error, and rendered scene are delivered there rather than to whatever the user is currently viewing. The drawer shows which conversation is generating, the in-pane spinner tracks the visible conversation, and each conversation restores its own scene on switch. Generated code can no longer open a native render window or corrupt the app's window.
A console panel and data-file suggestions
Captures stdout/stderr from running generated code (previously only in the server terminal) into a per-conversation Console tab. Lines are classified by stream, not text content - so a printed class name like vtkErrorCode is not flagged as an error. The console is now the single record of a run (run errors, generation/config errors, and the data-file resolver's "could not resolve" warning all appear there); the floating alert is removed, with a severity-colored badge on the Console tab instead. When a data-file reference can't be resolved, the closest known names are offered as one-click fixes via a "Fix data file" menu.
Testing
ruff, flake8, mypy, and pytest pass (the 3 pre-existing test_code_history failures are unrelated to this PR). New tests: test_console_classify.py, test_data_suggestions.py.
Much of this is trame layout, Monaco, and tab-rendering behavior that only surfaces in a live browser, not in CI:
Start a generation in one conversation, switch to another mid-generation - each should keep its own spinner/result/scene.
Trigger an error in a background conversation, then switch to it - the error appears in its console.
Run print(dir(vtk)) - shows as normal output (not an error), scrolls inside the console, doesn't collapse the render window.
Switch Conversation ↔ Console tabs repeatedly - render window holds its width.
Reference a bad data file (e.g. can.ex) - warning in the console + a working "Fix data file" dropdown.