Seems like especially for the last year or so, there have been a significant amount of interest in single-language oriented (instead of a single core library w/N language bindings, winking at a particular one) TUI libraries that are getting better and better (potentially because some of them were able to attract VC money). Two of them off top of my head is Textual (by textualize.io) for Python and BubbleTea (by charm.sh) for Go.
is there a good publicly available video that demonstrates what is good about these user interfaces, or alternatively, something that a non-expert user could run in dosbox to get a feeling? is the notably excellent part the user experience of the things that people built, or the library calling interface, or both?
business data entry seems like something that probably requires an experienced user running the application to show what's good and bad about it
my own 'baseline to beat' is fractint, which is pretty much unchanged in xfractint, which you can install from apt on debian. you just have to imagine it running fullscreen on a svga
The video is to display what an expert can do with it, if I understand correctly.
In undergrad, I worked nights in a warehouse where most things were managed by a very complicated TUI program.
The learning curve was quite steep. What someone could do after 6 months of using it was completely different to what a beginner without a trainer could do. You wouldn't be able to see what is good about it by just setting it up on your own computer and playing with it (and of course you probably don't have a busy warehouse to manage).
May be so, but Turbo Vision was not a unique interface paradigm. It worked just like any CUA application of the era, with dialogs and widgets, tab/funcion keys etc. Its "raison d'être."
Yes it did to a large extent, although I think some of the function key defaults were a bit different, probably from older Borland apps.
But by and large converging on a singular CUA/MDI interface from Mac OS, Windows, IBM, Motif, QBasic, and TVision, in the late 80s.
While not everyone got there 100% it did help tremendously that one could sit at a Mac/Win/Dos PC, Unix Workstation, or IBM mainframe and understand the application level interface immediately.
We're sadly losing that as "smart" people decide to hide things from "dumb" people in terms of interface design.
- spend an hour comparing recent turbovision-like libraries. spend twenty minutes building one. spend two hours working through the tutorial. spend sixteen hours building a new application using the library. use it. get a feeling for what an application using the library written in a weekend by someone with no experience is like. (this is my understanding of the alternative you're suggesting)
- spend eight minutes watching a video of a domain expert using a user interface built in turbovision by programmers experienced in turbovision, who refined that user interface over years. (this is what i was asking for)
which one do you think provides more insights into the textual user interface design space
Well, maybe you could spend a minute looking at the screen shots at the link and realize it works like every typical desktop app anyone has used since 1988.
TV is a classic interface in every sense of the word—it isn't pushing boundaries as perhaps you are looking for.
i notice that you haven't answered any of the four questions i've asked in my previous two comments, instead telling me a lot of things i already know (and also linking tvision, which is an interesting project, thank you)
to me this seems surprisingly discourteous
what do you hope to accomplish by such an abrasive interaction style
I see no question marks outside of the first post asking for a video. You also implied looking at TV would take an hour or more, which yes was mildly annoying.
Though I see the grandparent of this post reads more passive-aggressive than I was intending when I wrote it.
There are apps that are built on ratatui that support mouse already including an example in the repo[1], and crates (and some internal changes to the buffer) to support iterm/kitty/sixel based images.[2]
- Higher order combinations of widgets (e.g. combine the scrollbar and paragraph)
- Menus
- Any event system (apps bring their own - we just handle display)
- etc.
- There's lots of things in TV that are provided as external crates (like editors, treeview, etc.)
The main thing is that Ratatui is at least right now, just the display side of things. Things to do with events or application shell aren't built-in. This somewhat stems from the immediate vs retained mode approach to the library, but this may change in the future.
Core Ratatui dev here. Fun fact, I played a lot with these libraries when I was in a kid in the 80s/90s learning Pascal and C++. I never played with clipper though.
Because it did this on flicker-free(for the day) Hercules/MDA monochrome graphics.
I've experienced this 1st-hand while snobbishly commenting on that textmode stuff, while seeing friends dads working in their home-office, or sometimes in the living room on 'luggables' or early laptops, while myself enjoyed an ATARI-ST at the time.
Textualize and BubbleTea are both things I look to for inspiration in what Ratatui could be. Eventually, I'd like to make widgets look great with sensible defaults and support themes that allow for customization.
We use Charm's VHS for scripting the generation of images for all our examples, so definitely some thanks to distribute there in addition to the inspo.
The worst part is there's absolutely nothing stopping anyone from making the same principles work in the browser. Zero. Nada. It's trivially proven by compiling apps to wasm and running in a terminal emulator but there's nothing stopping anyone from building react-terminal-like or whatever except that... I don't even know what since we've got https://github.com/Textualize/textual-web.
People have thrown out decades of UX research and engineering out of the window because it isn't cool anymore. Makes me sick.
> People have thrown out decades of UX research and engineering out of the window because it isn't cool anymore. Makes me sick.
Most people don’t want to browse the web with a keyboard.
Traffic to many websites primarily comes from mobile devices with touchscreens.
It has nothing to do with being “cool”. Terminal interfaces are great for those of us who spend a lot of time attached to the keyboard, but most people don’t operate like that.
It's not about the keyboard, it's about discoverability and standards. Designers think their ideas are sooo good that they warrant overthrowing previously established norms of computer interaction. You now need to re-learn where things are for every new "application".
> Most people don't want to browse the web with a keyboard.
Site-specific keyboard shortcuts are a thing, they're important for accessibility. Unfortunately most sites either don't support them or do a poor job of documenting that support in a way that can be surfaced by users.
It's something I've thought about a little, but I haven't seen anything that does it. There's some pretty large blockers though. TUIs get by on effectively rendering text all over the screen, potentially out of order, and potentially without respect to whether that text makes any logical sense. AFAIK, There's no way to attach metadata to screen characters or regions that would mark up things as buttons / inputs / outputs / etc.
That said, I suspect that the right modality for accessibile command line apps is repls / cli apps rather than TUI apps.
In particular, curses(3) was the "virtual DOM" of its day, so its output can be arbitrary pieces of TUI elements, and it may and will re-render an element with different terminal control strings if it can save bytes on the wire (recall: this was at ~300 baud) by grouping neighbouring updates.
We're working on a new TUI for managing local and remote executions of optimization solvers like CBC, HiGHS, and our own hardware-accelerated solvers [2].
Ratatui is a delight to work with. It uses immediate mode rendering [3] which feels very intuitive compared to other TUI frameworks.
What beats that is a good GUI with all those features but without being limited by the clunky terminal host, which, for example, doesn't support all the power of the keyboard shortcuts
Is that a serious limitation, though? Sure, the terminal cannot support all the keyboard interactions that an old-style DOS TUI could use, but it can get pretty close for most purposes.
If you want to fly with a few shortcuts it is, otherwise no: most of the apps illustrate that "most purposes" can be served with pretty bad keybinding support
Thanks tosh, for sharing the project here! I'm one of the maintainers of Ratatui, and was pleasantly surprised to see this on HN.
I just wanted to add that we are welcoming contributions, so if you are interested please join us on GitHub for more discussions, feature requests or bug reports.
If you've built something cool with Ratatui, we'd love to hear about it on Discord or make it part of our showcase pages.
And if you are wondering what Ratatui is, check out our (fairly new) website for tutorials for getting started: https://ratatui.rs/
ratatui is very good Rust TUI toolkit right now. But, it doesn't support mouse click events yet[0]. I hope that they implement this feature as i think it's critical to some TUI applications.
It's a bit broader than this - Ratatui doesn't support events at all. It's not a UI framework, it's a display library (i.e. you call us, not we call you). That doesn't mean you can't do Mouse events (there's an example of this in https://github.com/ratatui-org/ratatui/blob/f767ea7d3766887c...), it just means there's not deep support for events in any way in Ratatui.
I think a lot of Ratatui apps will tend to land on similar concepts for your app. There's a few good examples of apps using a component approach rather than just widgets that I'm aware of:
If you like php, there’s termwind that combines html + tailwind. Combine that with something like the swytch framework, and you’ve got a pretty similar to react workflow (components, still working on hooks, tui, etc).
Love the SwiftUI inspiration. Swift has its warts but after spending a couple months deep in SwiftUI I miss it dearly when I'm writing GUIs anywhere else
Stuff like this is cool, and I like a nice TUI, but it’s really not for everyone. It always makes me think about how I’d like GUIs to be more like the TUIs I know and love, and what a pain it seems to be for the world to converge on good, simple GUI toolkits that aren’t HMTL+JS. Please don’t say QT or GTK+....
That was the result of wanting to do something to celebrate PR 500[1] and being repeatedly nerd-sniped by one of the other maintainers a while back. The source code for the demo[2] is in the repo btw.
Hehe - yeah, I needed an example for the table, and figured traceroute was a good easy one. Then I remembered what happens when you traceroute bad.horse...
I've actually got a ratatui update for glicol that I haven't pushed because I was stuck on a bug in the way the background thread continues after the UI exits. I'll flip you a PR.
There's also a matrix bridge and Github discussions if you'd prefer those options. It's difficult to choose a place to build a community - particularly ones that are non standard so Discord works for us right now. Have you got suggestions on other services that would work better for this sort of thing? Seeing examples of thriving developer communities in places other than Discord would help convince people that it's worth changing.
