docs: refresh and fill in Open Terminal screenshots - #1369
Conversation
5a63805 to
dccf78b
Compare
Classic298
left a comment
Classic298
left a comment
There was a problem hiding this comment.
additional infos
- maybe some screenshots for terminal orchestrator since that one has differences in the admin settings on what you can configure
- custom system prompt possible for open terminal and terminal orchestrator via env var in admin settings in the connection settings, maybe just a short note
- some pages i think still dont have screenshots. We can do those later, just putting this here as a side note
- other ideas (generally): DOCX creation, SVG creation/editing with subsequent display in chat, generally having the AI generate txt python docx pdf pptx files and having it use display_file to display those files inline in chat so you have an easy download button (download button can be highlighted with circle or similar) since that is a very common feature request and we should try to highlight that this is possible and easily so.
- personal preference: i really love the "find me X and display it to me" use case A) in general and B) when it even shows you the specific page where it is written on (PDF DOCX AND PPTX, for those three it will definitely work the page jumping). idk find me the page where in the manual it explains how to do XY or show me where it said that or "on one of the pages there should be an image ..." or "which of my files (have it even search the files first) has this written in it an boom it finds it an can even show you the correct page)
- maybe some more strongly chained workflows? combining OT with other builtin tools. Read some files and plan automations for recurring tasks, posting results to a channel, writing notes with new data, just throwing ideas out but this is definitely a follow up and out of scope here.
| ``` | ||
| ____ _____ _ _ | ||
| / __ \ |_ _| (_) | | | ||
| | | | |_ __ ___ _ __ | | ___ _ __ _ __ ___ _ _ __ __ _| | |
There was a problem hiding this comment.
weird example, also model doesnt end up showing anything
There was a problem hiding this comment.
missed opportunity to have it display it with a display_file tool call
There was a problem hiding this comment.
insanely valuable usecase, i love this, if you want put more of this since this is very valuable imho. If you want you can put more screenshots like these. finding pages in PDFs and displaying them is very valuable and also if the PDF contains PICTURES and your content extraction describes these pictures, the AI will even be able to find the images easily and therefore display you the file
There was a problem hiding this comment.
again would rewrite prompt "list what is in it" is redundant, the AI will read it anyways or unless.. you want to say "show me what's in it" or something? idk
There was a problem hiding this comment.
looks overwhelming - same file in the chat viewer looks better probably
There was a problem hiding this comment.
hard to read image, tiny text, maybe a bit more prettry chart
Resolves 28 of the 39 screenshot TODO markers across the Open Terminal docs, refreshes the 24 existing images, and adds new ones. Every screenshot is a full-window 3200x1766 frame, matching the framing of the images it replaces: the surrounding UI is the point of a product screenshot, since it shows the terminal selector, the file browser and where the reply appears. Screenshots were captured against a throwaway Open WebUI instance driven by Playwright at the same 1600x883 / 2x scale as the existing set. Every artifact shown was verified on the terminal's filesystem rather than against the screenshot, since the model will happily narrate files it never created. The access control frame is populated with placeholder users so the groups show real membership counts rather than zeroes. Five briefs asked for pictures of shell output. Those are code blocks now, using real output: the Open Terminal startup banner, docker stats from a container started with the documented --memory 2g --cpus 2, and docker compose up -d. Four briefs asked for diagrams and are now mermaid, matching the blocks already used elsewhere in the docs: container isolation, internal:true networking, Docker socket exposure, and the connection-URL diagram. Also: - connecting.md described a green "Connected" indicator that the UI does not show; the saved connection appears with an enable toggle instead. - file-browser.md reused one generic screenshot for three different claims; two of those now have images that show what the text describes. - The egress filtering section gains its real startup output and a note about the added capability it needs. Eleven TODOs remain and are left in place. Four need infrastructure this pass did not have: PostgreSQL (database-analysis), web search (research-assistant), a multi-user terminal, and a generated PDF page (data-reports). The rest are in configuration.md, multi-user.md and installation.mdx, whose briefs ask for pictures of commands and config files those pages already print as text.
dccf78b to
e74abfb
Compare
|
Thanks, this was useful. All of it is in except the parts noted at the bottom. Re-shot with the prompts rewritten
Duplicate screenshots Correct, and it was a regression I introduced in this PR. Making every frame full window turned
Trimmed. The startup banner is down to the address and key lines, which is the part the original TODO asked for. Find it and show me the page Added a second one on a Word document, where the file is located first and then opened at the right page. Happy to add more of these, including the PDF-with-images case you described, though that one needs content extraction that describes the images, so I would rather confirm that works before filing it as documentation. Two that are not screenshots The Filesystem setting already has prose: Not done here Orchestrator admin screenshots need a real Terminals orchestrator, since Open WebUI decides the type from what the server reports and my capture instance is a plain Open Terminal. I did not want to fake the panel. The file generation set (DOCX, SVG, PDF, PPTX shown inline with the download button highlighted) is a bigger piece of content, so I am doing it as a separate PR rather than growing this one. Pages with no screenshots yet and the chained workflow ideas are left for the follow up, as you suggested. |
|
Split out the file generation set as #1370, per the scoping above. |
Works. Needs content extraction engine that describes PDF as markdown and describes images in it. E.g. a custom external exctraction server that uses a vision model like gemini to describe in markdown and images in a structured way |
standalone PR would be good here |
There was a problem hiding this comment.
omit full file path loooks unnatural
There was a problem hiding this comment.
doesnt look good, sidebar too big also
2 participants
Summary
Picks up @Classic298's ask: the Open Terminal screenshots were outdated, some pages had none, and
display_filewas underrepresented.This resolves 28 of the 39 screenshot TODO markers, refreshes the 24 existing images, and adds new ones. Every screenshot is a full-window 3200x1766 frame, matching the framing of the images it replaces. An earlier revision of this branch cropped the chat replies down to just the assistant message, which stripped out the sidebar, the terminal selector and the file browser panel. That was the wrong call for a product screenshot and all 19 affected frames were re-shot full-window.
Not every brief wanted a picture. Five asked for screenshots of shell output, and those are code blocks now using real output: the Open Terminal startup banner,
docker statsfrom a container actually started with the documented--memory 2g --cpus 2(67.57MiB / 2GiB 3.30%), anddocker compose up -d. Four asked for diagrams and are now mermaid, matching the blocks already used elsewhere in the docs: container isolation,internal: truenetworking, Docker socket exposure, and the connection-URL diagram on connecting.md.Three corrections came out of the pass:
open-terminal:latestmeasures 3.97 GB against the documented "~4 GB".Related issue or discussion
No linked issue. This is a documentation pass on the Open Terminal section, raised with me directly by @Classic298.
Checklist
Notes for reviewers
How the screenshots were made. Captured against a throwaway Open WebUI instance driven by Playwright, at the same 1600x883 / 2x scale as the existing set. Every artifact shown was verified on the terminal's filesystem with
docker execrather than trusting the screenshot, because the model will produce a convincing frame describing files it never created. Three frames were discarded rather than shipped, for that reason or for poor framing. The access control frame is populated with placeholder users (alice@example.comand friends) so the groups show real membership counts rather than three zeroes.One thing worth a second opinion.
OPEN_TERMINAL_ALLOWED_DOMAINSis a real dnsmasq/iptables allowlist and the domains load correctly, but the container then exits at startup:Reproduced with
--cap-add NET_ADMINand withNET_ADMIN + SETPCAP, on rootful Docker with cgroups v2. I documented the allowlist with its real startup output and added a note about the capability requirement and this failure mode, but I did not writecurloutput I could not actually produce. This may be a genuine bug rather than my host, so it is worth someone confirming. The dashes in that block are verbatim program output, left unaltered.Eleven TODOs remain, all left in place. Four need infrastructure this pass did not have:
MULTI_USERterminalThe rest are in
configuration.md,multi-user.mdandinstallation.mdx, which this PR leaves untouched. Their briefs ask for pictures of config files and commands those pages already print as text, so they may be better closed by a decision than by a screenshot.npm run buildpasses clean.