[em-bee]

streaming video services and Fortnite

those are not remote graphics applications. streaming is one way, and on slow connections it still fails. fortnite is local graphics. like a webbrowser. i already mentioned that. by remote graphics i mean a GUI application that runs 100% on a remote machine, and displays the output locally. like streaming, it depends on a fast connection. unlike streaming the fast connection needs to go both ways and it needs low latency (streaming doesn't need low latency, it just needs bandwidth.

your other example is similar to mine. but, in my opinion there is no reason why we couldn't have better graphical visualization of the commands we type. the browser model seems to be the right approach. local graphics working with remote data structures.

[skeledrew]

> streaming is one way

But has to be reasonably performant for a decent experience.

> fortnite is local graphics

And commands have to be sent to the server with minimum latency.

Bringing the capabilities of streaming and online gaming together means VNC is a non-issue, as the 2 have far more stringent requirements than the latter. A VNC connection is primarily streaming small diffs for the majority of a session (only occasionally does the full screen need to be sent) and input commands which aren't very latency sensitive; there isn't much to it.

> better graphical visualization of the commands we type

It's possible, but not necessary, and is counterproductive when it harms accessibility, which it often does. The browser is the worse thing out there IMO, because web devs are pushing JavaScript everywhere and hurting the experience for many. Things are supposed to function well for the user, but the focus nowadays is on shoving meaningless animations into things that should just be simple text, and ads into everything, which inevitably leads to far more noise rather than function.

[em-bee]

the focus nowadays is on shoving meaningless animations into things that should just be simple text, and ads into everything, which inevitably leads to far more noise rather than function

right, but the same is true for all GUIs to an extent. which is why we still feel that TUI and commandlines are more efficient.

what we really want here (or what i want) is a locked down GUI that is efficient to use and designed to display the data that the commandline tools produce. no fancy graphics but a meaningful graphical interface that is not tied to the app that produces the data.

the problem now is that we have two choices, either we write a commandline tool that just spits out unstructured data, or we design the whole interface ourselves down to the last pixel. there is nothing in between.

think about the window manager. X11 used to work like that. windows would just display minimal frames, and the windowmanager would add the decorations to manipulate the windows. all windows look and work the same. in whatever style the windowmanager offered. that's gone now. the decorations are part of the window. that has some advantages, but also downsides.

the web has the same problem. i can't just send structured data. i have to send the whole interface. there is no separation. data and interface are merged in my app. at least now with javascript i can build apps that allow me to pull structured data from the server and display it, so data and app are kept separate. that's what i want on the commandline too. with the terminal functioning as that app that knows how to display the structured data that my commandline tools produce.

[skeledrew]

> a locked down GUI that is efficient to use and designed to display the data that the commandline tools produce [...]

You can have all that. There are various data presentation tools out there (one I can think of right now is Streamlit as I tried it out a few months ago, but I'm not really a data person, Python is just my primary language). For a more general GUI framework that's pretty easy to use and still full of features without tying anything you can look at Flet[0]. Heck Jupyter too is built specifically for processing and presenting data, and can keep things as separate or combine as much as you need.

There are many solutions out there that work really well already, particularly in the Python ecosystem. The all-or-nothing is mainly an ecosystem issue IMO, as web devs don't do much data processing that isn't accompanied by immediate presentation; the web browser is primarily a presentation engine after all.

Don't look to TUIs for good presentation as the terminal just isn't the place for fancy views. It's designed strictly for organizing and displaying - preferably streaming - text, not graphics. Also think of it as a relic from the old days when there were only text displays, modernized in many ways but still bound to those roots. Trying to make it behave like a graphics display is like trying to fit a square peg into a round hole, unless the particular terminal has that support specifically implemented.

[0] https://flet.dev/

[em-bee]

Don't look to TUIs for good presentation as the terminal just isn't the place for fancy views

yes but the terminal is still the place where most of the sysadmin and dev work happens. it's a relic that we can't get rid of.

unless the particular terminal has that support specifically implemented

which is exactly what i am aiming for, reinventing the terminal to get support for that built in.

[skeledrew]

Sounds like you'll more likely than not be crafting that terminal yourself; I'm unaware of any that goes the lengths you seem to desire. But that's actually not that big a deal nowadays given the quality of LLM agents.

[em-bee]

there are a few projects with interesting ideas already, warp terminal, which was recently released as FOSS is one, ttyphoon is another. both are not yet where i would want them to be in terms of data display, but they show that reinventing the terminal is possible and hopefully these ideas will get more mindshare