> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc.
Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham.
Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy experience on Linux, you can use RemoteApps on Windows to have a good remote experience (but almost no other platform), you can use VNC to have an awful cross-platform experience, or you can use a TUI and have all the graphs and interactivity you need over a responsive, low-bandwidth connection on any combination of client+server.
> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X.
Basically, you write your application on top of a GUI framework that smooths over OS differences for you.
I suspect the u ubiquity of electron persists more because maintaining both web and desktop interfaces is somewhat simplified, and as a corollary, you don’t need a separate JS and C/C++/QML team. Qt has gotten pretty good, but JavaScript and typescript are easier to hire.
I think Qt is a bit different here because of Qt Quick etc but I've tried using "native" GUI frameworks a lot and ultimately the web DOM model is pretty nice for iterating easily.
Querying into the DOM and working off of that means you're not futzing about holding onto a bunch of component references for the one thing you might need later on.
Web layout is also pretty easy to just get right, native GUI frameworks have a different kind of layout model that is not as amenable to "arbitrary" data (at least at first blush).
the reactive programming model also works quite well. While there are native GUI frameworks that lean into reactive programming, they tend to be doing a bunch of weird stuff that cause other issues.
And at the end of the day, when you package something like a Qt app it still often ends up being quite chunky.
In the end tho... the simplest thing is if you do web stack you get a web UI _and_ your "native" GUI in one go. Build things once, not twice. Hard to argue against that when that's presented.
they wont work on android though. thats the main reason i started using more TUIs myself. i needed to be able to run a bunch of python scripts on linux, windows and android/termux. or if any of the linux phones ever matures, or sailfish, then the same scripts will run thereas well, probably without any modifications needed
KDE has a framework based on Qt's QML that works on Android. It is called Kirigami. They have written apps and even a complete Plasma Mobile using it. The apps work both on Android and Linux.
Mobile has significant paradigm changes that makes using both terminals and traditional GUIs harder anyway though. I do expect the need for completely different cross-platform libraries for mobile UIs.
It is trying to fit GNU/Linux into Android/Linux, on a model that has only worked so far because internal politics have prevented the replacement of Linux kernel with Zirkon.
The official NDK documentation on what is supported for NDK written code on non rooted devices, and the hurdles that Termux faces to keep running on standard Android images via PlayStore distribution, show why it isn't right.
I really think they are. The reason for terminals’ ubiquity is precisely their age, and their age results in them standardizing and accumulating bizarre behaviors.
Even in the microcomputer era, standardizing behavior to where it’s literally everywhere someone might want it takes time (e.g. the browser compatibility wars). Re-standardizing terminal behavior is both chasing a way wider (in terms of the number of places folks expect terminals to work the exact same way) but shallower in feature complexity target compared to browsers, and would necessarily be replacing a widely adopted existing standard behavior, not providing something largely novel like the graphical web was. That’s a tall order. I am hopeful for and impressed by the efforts of folks like Hashimoto, but expectations here should be tempered.
Basically any OS can install any compliant terminal emulator, meaning the cases in which you really have to patch your TUI for another OS are few and infinitely more manageable than GUIs
How so? The idea is you build all the OS specific stuff into the terminal, not into the programs running INSIDE the terminal. Think Infocom Z-Machine, at the ultimate level, although obviously emulating a full on virtual CPU is overkill.
In any case we can surely do better than emulating DEC hardware from 50 years ago.
It depends. If the OS can run e. g. ncurses, you have access to quite a lot of software here, such as htop. Though, I am not sure if it works on windows; but I think it works on OSX. Windows is very strange.
That ubiquity is the reason for the limitations of terminals/TUIs discussed in grandparent. Those two are not separable: they’re everywhere precisely because they target the lowest, oldest common denominator (teletype console behavior assumptions from the 1960s).
”GUIs always look bad outside of the "main" platform.”
I think this is slightly wrong in two ways.
i) If you want platform native then reimplement the gui on every target platform. It’s as ”simple” as that.
If you need to ship to multiple platforms then preferably you need lots of plarform specific engineering in any case.
”I just want my hobby tool” scenario likely does not require cross platform support unless there is market for it. I mean rather than offering the tool on multiple platforms it should be offered on multiple languages first, perhaps. As soon as you are not writing the tool for yourself we are talking markets and distribution. Likely most people can chill out and just implement the gui for themselves (and not even publish it in githubb).
ii) cross platform quick-and-dirty way. Without screenreader support, multiple language and glyph support etc.
Game ui:s look the same on all platforms. Websites look the same on all platforms.
There is place and time for deep ui engineering that respects the _critical_ cross platform issues like accessibility (screen readers etc) and different languages and scripts.
And then there is the situation where you want just few images to click. The latter is vastly simpler, fast and fun. But harder to convert to a professional quality gui experience. For small tools and MVPs this sounds like a fair tradeoff.
There is not much difference between a TUI and a GUI once the premise is "let's start from scatch all other again for each applications". Sure then there is no guideline that comes between idea and implementation. But there is also no built-in accessibility, UX best-practices and many specificity of handling a vast experience of building something stable over a large period of time with many feedback from many different scenario.
Html has also some of these properties, targeting the browser. Don't get me wrong. I do like TUIs, they are light weight and compose very nicely with the rest of the terminal (eg tmux). Also, i generally prefer just cli commands over tuis when possible.
TUIs would be great if they didn't have to render all text the same size, for me that's the main win with GUIs, you have total freedom with what you can do with your pixels.
I would definitely be pro minimalist unicode-character-themed GUIs for what it's worth. Where every graphical primitive is basically a unicode character, without the restriction on font size.
Sending drawing commands to an X server is no more difficult than sending escape code sequences to a terminal. Simpler, even, because it's actually designed for that. And yet it's also more flexible. If your GUI framework of choice is limiting you, you're welcome to write one, just like you're already writing a TUI framework.
> cross-platform GUIs always look bad outside of the "main" platform
qBittorrent looks great on KDE, and would look great on macOS too if they used native icons (I’ve made a theme for that but was too lazy to install it when I was switching laptops). No idea about Gnome and Windows, but probably alright as well.
So, Qt can get you a long way. But you should of course adapt your app to platform conventions and guidelines.
You can't stay engaged if the menus don't bleep and bloop at you and confetti rains down on every click? That's a personal problem. A minimal UI is not automatically a bad-looking UI.
No, but I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted". I don’t want to read docs to find all keystrokes the TUI supports to achieve what I want.
>I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted"
sounds like your terminal emulator is just crap, terminal and iterm on mac just work
It’s trivially easy to run a TUI in a container. Not so much with GUIs. And, since I run as much as possible in containers, and as little as possible on my host machine, I much prefer TUIs.
there's a million gui frameworks under the sun and i still haven't found one that feels like what everyone has been asking for:
good dx, cross platform, fast, not ugly.
pick i dunno 2 or 3.
tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here.
now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made open immediately running in ghostty? hell yea. with that said yes there are some stupid tuis out there that are anything but simple.
That depends what is build and how. Granted that a modern web browser is indeed an order of magnitude heavier than an OS, once that ticket is paid anyway, one can built very far, without relying on any additional bloat that contemporary web frameworks puts on top of it. There is not that much more data to send though HTTPS to bring a far more convenient UX than what raw text bespoke tweaks can offer over SSH.
Not “not ugly” either. The flexibility is too high and standardization of UX is too low. Technically, we’re missing adoption of default standard toolkits like swing or GTK, and politically a11y/compliance checkers are a far cry from something like the HIG of old.
Agreed. This is exactly what I want, ideally with components and libraries and panels and data shareable and extendable between applications.
The closest in spirit is Probably something like Dear ImGui[0] and the ecosystem of components and apps built with it, but it's not quite there for me. Something is missing.
BearLibTerminal might be something on this line, although its purpose is mainly for developing rougue-like games. It simulates a terminal in a GUI with a high-level API
Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant.
Today the closest you might be able to say is web/electron, which is gross on all counts. If anything the closest is X11, which is not remotely close enough.
we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that.
I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth.
My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy.
Now when I go to `http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically.
Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
Rather than typing http://localhost:8022, name each app and put them behind one local proxy:
1. In /etc/hosts (or dnsmasq): 127.0.0.1 ourapp.test
2. Caddy in front: ourapp.test { reverse_proxy localhost:8022 }
Caddy auto-provisions local certs, so you get https://ourapp.test, no ugly ports and no "not secure" prompt.
For the overview idea: a tiny local dashboard that scans common dev ports (3000, 5173, 8080...) and lists each running app by name is a ~100-line utility. This is exactly the kind of small tool I build, happy to make a quick version for you.
Definitely not weightless. So much bloat has been dedicated to various frameworks for it, and modern browsers are notorious for how much RAM they require. I'm particularly reminded of this each time I try to visit websites on one of my older Raspberry Pis. You are just pushing much of that complexity and overhead to the client.
Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?