What would people do to not use a proper GUI library.
The question is, why do people choose the terminal instead? I can think of several possibilities:
Cross-platform is easier? I'm overly simplifying but it's basically either this or Electron.
Integration with the terminal ecosystem? @tstack already mentioned SSH.
Less intimidating mental model? It's "just" a grid of cells: anybody can do it and expectations are lower.
Allure of constraints? The character grid attracts hobbyists because it's fun to shoehorn a GUI into it.
Assuming that the terminal is in some sense an inferior technology for building a GUI, there must be some reason why people keep choosing it as a starting point.
My reason is that it's keyboard-first. The only real TUI app that I use is (neo)vim, and I switched to it from VS Code because I was tired of having to shift my hand over to the mouse so much.
The limitations of a terminal emulator dont allow for over complicated things. The number of visual elements cannot possibly be too high. And the application needs to be keyboard driven which I find to be a huge ergonomic/comfort/quality of life win.
They are also generally faster and nimble, and expected to work without visual glitches.
I grew up in the the 80s/90s and some of my first terminal GUIs were things like DOSShell and such prior to windows being a thing. Not a massive fan of going as far as building a full GUI, but I do want stuff to look good and get some of the usability stuff that comes from GUI research, this feels like a small step in the right direction.
GUIs definitely have their place. I much prefer them for coding agents for example (I say this as someone that worked on the Codex TUI).
There's lots of things that make sense as a TUI though, but this feels like it's one of those things that holds it back a bit. Raph (Rio maintainer) has a custom glyphs proposal that does a bunch of fun things as well. https://x.com/raphamorims/status/2120887890129388001
Can you expand a little what distinguishes this from a full GUI, especially in light of projects like https://github.com/cyber-wojtek/waytermirror, which render Wayland into a terminal with sixels?
As far as I can tell, the main difference is the kind of styling that's easy to do, and the amount of fallbacks and variations needed if your terminal handles different features differently in termcap.
This is just a means to put lines between cells. Colored, segmented, siimple.
GUIs are about arbitrary placement of components. Terminals are cell restricted.
Yes you can build a GUI on a TUI if you want (by handling all the painting yourself), but this spec is not about that. It's agnostic about what you do with the borders. It fills a gap (literally). You can use that to make a GUI, but TUIs ain't GUIs.
I'm not sure why they're not considered GUIs. As capabilities get added, the distinction seems like it's become negligible, and the main difference seems to be that the rendering is flakier and less capable.
They are GUIs. The main distinction, as far as I can tell, is that there's a little bit less setup to access them remotely, in exchange for a worse user experience. But that additional setup doesn't seem to be a fundamental limitation of the technology.
With all the visual protocol extensions like this, sixel, etc. it’s like we really want to reinvent the Blit terminal but can’t quite bring ourselves to cross that line.
I develop a log file viewer TUI and have resisted turning it into a GUI when people ask. Part of the reasoning is that it needs to work over SSH. The other part is that I find GUI log viewers are filled with junk that takes away from seeing the actual log messages. I like to complain about datadog/grafana/etc because there is so much ornamentation and other stuff that you end up with a fraction of the screen real estate for the meaningful text. Ultimately, the TUI forces you to focus on what matters.
I also like to complain about TUIs that put borders around everything since it wastes precious space. So, this is nice to see.
I really don’t understand why people keep on doing frames with gaps between them. It’s just ridiculously wasteful. In terminals, increasingly in window managers (I feel like it happened first as a tiling window manager gimmick under Linux, though maybe it was macOS, which was always really bad about wasting space in full-sized windows), even Firefox is now succumbing to this latest stupid design trend which has a terrible tendency to completely undermine content hierarchies.
Why this?
┌──────┐ ┌──────┐
│ Text │ │ Text │
└──────┘ └──────┘
┌──────┐ ┌──────┐
│ Text │ │ Text │
└──────┘ └──────┘
You don’t need the outer borders, and you can collapse the inner borders. Now, taking the same lines and columns, it can now even be ridiculously overspaced:
│
Text │ Text
│
────────┼────────
│
Text │ Text
In this article: the panes example doesn’t feel like it needs extra borders and gaps, and the fallback behaviour isn’t entirely how you could reasonably expect it to be done: the header line could be integrated into the border (┌─███████░░░░░░──────┐ with text on the shaded areas). The chart example shows how it’s already abusing things (see how obviously it’s irregular); why not go fixing that with some addition? Or just rendering an image for the entire thing? You honestly might as well at that point.
I would also just like people to stop trying to turn terminals into compositors; TUIs (as distinct from CLIs) are all kinds of problematic. The cellness of it all is a fairly extreme limitation, and we really should stop trying to force GUI-shaped objects into terminal-shaped holes. Keep it simple, generally try to limit yourself to stuff that would still work with a proportional font, and embrace the very limited colour palette you get given. Or else make a GUI.
Terminal emulation is already way too complex.
Yours sincerely,
A dyed-in-the-wool vim user
(who would nonetheless like to be able to code in a proportional font without having to switch editor)
I really don’t understand why people keep on doing frames with gaps between them.
They make for superficial but attractive demos that challenge only uncontroversial or inconsequential preconceptions without demanding much else from the viewer.
In other words, you can put together something that looks kind of pretty (if you're just scrolling and don't occupy yourself with how you would use the programme being demonstrated); that looks very similar to something you're very familiar with (often, the demos involve recreating well-known GUI applications); that challenge the preconception that terminals and window managers are very separate and distinct things; that challenge the preconception that terminals are very obscure and difficult-to-use-things; that reässure the viewer that the purported complexity of creating, maintaining, packaging, or distributing a GUI may somehow be avoidable (after all, creating a “CLI” is so easy, it's where most introductory educational materials for programming start!); but also do not challenge the viewer to consider that to create an interface of high utility, there is an unavoidable and often very significant level of effort required (irrespective of the interface medium); and do not challenge the viewer to consider the serious gaps in their own knowledge (e.g., that, despite their years of experience using CLIs, many don't even understand how to design a good CLI of any moderate complexity†!)
† Seriously, most corporate CLIs are so preposterously bad, I wonder what they're even teaching people in school. It's a marvel when you run across one where the author considered, even fleetingly, “maybe we could read (line-delimited) input data from stdin…?” Frameworks made this worse. With LLMs, there is no hope left. (Median LLM CLI design is atrocious.)
In the era where creating demos required significant effort, we'd often marvel at what someone could create, and our attention would move on before the discussion would ever move to considering “is this thing actually useful?”
A friend of mine recently used an LLM to quite faithfully recreate the Bloomberg interface for financial data analysis. They didn't write a single line of code. It took about a weekend of work. Five years ago, this would have gotten them an unending stream of job offers. Today, instead, they got a bunch of social media posts… and a few days later, no one cares. Does the thing look very slick? Yes. Does it actually work? I guess? I don't know if anyone on social media even installed it. Does it do anything better than a Bloomberg terminal? Who knows? Is it competition for Bloomberg users? Probably not. Is there anything we can learn from their code, their design, their effort? No.
Setting this aside, your underlying supposition—one which I share—is that the various interface media (in this case, terminal-based vs window-manager-based) are sufficiently distinct that their design demands specific effort. An interface design that works in one medium will not “fit” in the other. Designing for a GUI should be very different than designing for a CLI or TUI.
If we investigate more closely, it's pretty clear that there are extremes where this assertion is obvious true and where this assertion is not obviously true. That is, on one extreme, we have programmes like, say, (the simplest version of) top which probably wouldn't look very different as a GUI. At the other extreme, we have CLIs, and I don't think I even need to name an example to help conjure a vision of a workflow that is impossible to reproduce as a GUI. Somewhere in the middle are TUIs, which I think are on unsteady footing, though I think terminal protocol extensions (such as those proposed in this post) are actually mostly harmless.
As you note, TUIs seem to demand a different design approach than GUIs, as a result of their cell-orientation and other related fundamental limitations. For example, because cell size is uniform, all graphical elements are uniform, and because “zoom” operates at the terminal level, we don't have dynamic resizing; therefore, your terminal window is generally sized and zoomed to the cell-size of the least important text in the interface; therefore, your terminals $LINES and $COLUMNS are always too few; therefore, we're often cramped, wanting for more space, and sensitive to extraneous whitespace like border padding.
I agree completely that a direct consequence is that visual style must subsequently adapt to these limitations to produce useful tools that are not simply demo-ware. From this perspective, the terminal protocol extensions proposed by this post would actually be very useful; however, it's probably fairer for the author to include as comparison a fallback mode of their demo programme that eliminates the visual styling. (This is basically what I would do, if I were writing such a programme: use all-edge borders more freely in the presence of the protocol extension and fallback to separating-edge borders or no borders in its absence, not just because it will likely look nicer and be less wasteful of space, but also because it will minimally inhibit naïf cut & paste.)
Similarly, as you note, it's true that TUIs are almost always a clumsy and discordant cramming of GUI metaphors into a foreign medium. However, I don't think that TUIs have to be this way. In fact, I suspect that there may be as-yet-undiscovered metaphors for TUI operation that provide a materially better interface to users than a CLI or GUI. That is, rather than considering the TUI as somewhere between a GUI and CLI, I suspect that the TUI may be it's own unique, distinct paradigm that has its own unique, distinct way of being operated. I don't know if there are many applications whose most effective interface is manifested in this medium, but I am fairly certain there are at least some.
Personally, I have recently been exploring the idea of programmatic, “non ad hoc” terminal multiplexing as an avenue for exploring this space further, and I think there's utility in this, but it's not clear whether there is really that much novelty, and I actually kind of doubt the idea will prove to be that revolutionary (but, still, probably very useful!)
However, it's probably fairer for the author to include as comparison a fallback mode of their demo programme that eliminates the visual styling. (This is basically what I would do, if I were writing such a programme: use all-edge borders more freely in the presence of the protocol extension and fallback to separating-edge borders or no borders in its absence, not just because it will likely look nicer and be less wasteful of space, but also because it will minimally inhibit naïf cut & paste.)
Yeah, that's in there already - press b in the demos or just run it in a terminal that doesn't support this - i.e. all of them. the screenshots inthe article are show the fallback and note the problem.
Definitely not a necessary part of the spec - more something that I prefer on this and to demonstrate it in comparison to the existing solutions - the space makes it more clear there. But the thing about text is that words inherently need spaces between them to be readable. And TUIs exist generally in this weird text heavy, multi server / OS, keyboard focused, type heavy where GUIs aren't quite appropriate and people try to work around various shortcomings in the best way possible. Often the idea 'use a gui' is just not a relevant answer to the problem in the same way as why not use the vim gui isn't an answer for you.
There's a bunch of example TUI apps on https://ratatui.rs/showcase/apps/ that show various versions of what people tend to do in the terminal. These tend not to be the ones that I was saying were the problematic ones. But I'm sure they'll annoy your border sensibilities.
Unsure if you've posted something similar on hn a while back or if that was someone else, but I agree with you generally. I push back a bunch on bland boxes and borders apps a bunch in feedback
Press c (or start it with TILING_PANES_COLLAPSED=1) and the panes sit edge to edge: no outer border, one shared line between neighbours, ┼ where they meet. With box drawing, every shared line still costs a row or a column. With cell borders, the line sits on the cell edge and the text keeps the whole pane.
The thing you'll notice is that the color of the border has to be owned by one of the cells on either side of it, so the approach here where borders are between cells neatly solves that problem
counterpoint: the most popular cell-oriented user interface out there is the spreadsheet, and cell borders have been a valued part of the design forever.
Ghostty is starting to remind me of Chromium; a place where new standards for a platform are unilaterally inserted and by which others are pressured to adopt due to popularity. I don't want to end up in a world where 90% of "TUI" apps actually require ghostty and will not render reasonably in any other terminal.
It's just where the energy is right now. iTerm2 and kitty have previously been places where that has happened a bunch in the past, xterm before it. Ghostty is different because of the rather unique nature of Mitchell doing a passion project combined with the LLM hockey puck nature of software development capacity and a need of people to massively parallelize command line stuff generally due to the same need for tooling. We're in a bit of an AI gold-rush era if you look at it that way.
I don't think that's a bad thing unless Ghostty were closed source, but it's MIT. You can rewrite it in rust if you want it (I've done this). Implement your own stuff on it if you want to (this too obv).
I also implemented this originally with Rio - same level of difficulty generally, and Raph has been pretty supportive of doing something with it.
I posted it on the Ghostty discussion because it feels right to get it in a real world terminal that many devs are gravitating to. Happy to post this other places too for it to be seriously considered as a proper option. But if you look at the recent OSC7501 stuff and how fast it went from Ghostty spec to implemented in a bunch of other places it's worth considering treating it as a place to start conversations around this sort of thing
Ghostty is starting to remind me of Chromium; a place where new standards for a platform are unilaterally inserted and by which others are pressured to adopt due to popularity.
I feel similarly ambivalent.
Ghostty is a fine terminal emulator (but I haven't tried all of the new ones, though I do also like WezTerm… and I should really try kitty again, since I had a really nice time meeting its core developer at PyCon India, who is really a lovely person.)
libghostty is extremely useful. As part of some background research, I was looking into the most minimal terminal multiplexer and collecting short examples (similar to the list of X11 window managers with <10k lines of code.) I intended to use these as a starting point for developing my own ideas; however, I abandoned this approach after creating a simple demo in Zig using libghostty. In fewer than a couple hundred lines of Zig code, I was able to create some very complex proofs-of-concept on top of the libghostty state machine (which is both easy to use and fairly complete.)
However, I would love to see more competition. libghostty is useful and good, but I think it's possible to create a better library for the underlying state machine—better from a performance, code quality, and design perspective. Furthermore, there's still a lot missing from libghostty, namely supporting functionality. That is, the proofs-of-concept that I was able to create in a couple hundred lines of Zig could have been even shorter, if I did not have to write some minimal helper libraries around the edges of the state machine. (To be fair, some of the helper libraries cover gaps in the Zig standard library—e.g., conveniences around system calls like fcntl or ioctl…) In fact, there may be even be a way to design the state machine API such that we can address complaints about common tools like terminal multiplexers.
We know that consolidation can occur very rapidly in some circumstances, and they look like those we currently inhabit (e.g., your coworker whose argument is “well, that's what they're trained on,” when advocating against adopting new technologies,) but diversification can also occur very rapidly in circumstances that also look like those of the day (e.g., your other coworker's counterpoint that the bulk of the tedious effort involved in adopting some new technology can be done at very low cost.)
Terminal emulators have historically evolved very slowly, and this conservatism obviously has upsides and downsides. Many of us have come to terms with or have found coping strategies to mitigate the downsides, so we experience the conservatism as mostly a positive thing, preserving a useful, working environment. (As another comment here states: “terminal emulation is already way too complex.”) This more rapid evolution may seem disconcerting, but I think it's worth considering the goals of the kitty terminal protocol extensions:
The goal of these extensions is to be as small and unobtrusive as possible, while filling in some gaps in the existing xterm protocol. In particular, one of the goals of this specification is explicitly not to “re-imagine” the TTY. The TTY should remain what it is -- a device for efficiently processing text received as a simple byte stream. Another objective is to only move the minimum possible amount of extra functionality into the terminal program itself. This is to make it as easy to implement these protocol extensions as possible, thereby hopefully encouraging their widespread adoption.
Considering this, I think there's a case to be optimistic. If the evolution of the terminal protocol is as deliberate, as considered, and as thoughtful as this goal suggest… then maybe we'll be okay?
I think it's possible to create a better library for the underlying state machine—better from a performance, code quality, and design perspective
I'm working on something for that specific point, in Rust, every terminal spec, async request reply on queries, with proper timeouts, etc. Slowly as a background sleeper project when I have tokens and attention in sufficient quantities to burn.
Ayman Bagabas is also doing something similar with uncurses.
If you were to level such a claim at any terminal, I think that terminal would be Kitty: Kitty Graphics Protocol, Kitty Keyboard Protocol, multiple cursors protocol, drag drop protocol, etc, etc, etc.
As restrictive as using ASCIIUnicode art for drawing minimal outlines in terminal output, they have one big benefit. This cell border feature has the same drawback as leveraging colors for differentiating sections of the output. It breaks copy/paste by losing semantic info that might be needed.
Looking at something like rustc's output, we could make the gutter where the line numbers are be one to two cells smaller by using a different background color, but then copying that or using NO_COLOR would make the output no longer look as easy yi glance.
For TUIs that drawback is less pronounced because most people don't expect to be able to copy the app's output, and the app can detect that it is in NO_COLOR mode and change the rendering.
yeah, there's definitely going to be downsides on this. Even doing alt mode vs normal wrapping mode in TUIs can be a problem for copy paste, as you get hard lines instead of soft. This is why e.g. lnav has a keybind to turn off all chrome and spit out the screen to the terminal as is.
I wouldn't suggest using this in non TUI contexts most of the time.
That said, it's possible that the terminal could also handle how to present this when copying and this becomes implementation detail rather than an actual problem.
The log example's borders touch the text which is looks pretty bad IMO, and might make reading harder depending on the language.
I wonder if the protocol can mandate a visual separation.
yeah, there's various bits I'm not 100% happy with and this is one. I think I'd like to consider this maybe as expanding out from the text somehow into the surrounding cells, that might help this a bit better. That way you still lose the next cell over but can have a natural padding area that extends the bg color automatically or something like that.
Yes. assuming the terminal is well behaved. As a simple test, both the Ratatui apps degrade fine in tmux under terminal.app if it's any indication of things not breaking hard (notoriously a painful combo). The detection logic in the spec is just normal stuff you'd expect.
pointlessone | 10 hours ago
What would people do to not use a proper GUI library.
I mean, it’s cool but we’re like this close to adding
inset,outset,groove, andridgestyles and it’ll be basically Motif/win95, only on a grid.bitshift | 5 hours ago
The question is, why do people choose the terminal instead? I can think of several possibilities:
Assuming that the terminal is in some sense an inferior technology for building a GUI, there must be some reason why people keep choosing it as a starting point.
cyberia | 3 hours ago
My reason is that it's keyboard-first. The only real TUI app that I use is (neo)vim, and I switched to it from VS Code because I was tired of having to shift my hand over to the mouse so much.
jaculabilis | 5 hours ago
There is also a certain amount of "hacker cred" that comes from using a terminal. Humans are not immune to social status incentives.
pm | 19 minutes ago
The limitations of a terminal emulator dont allow for over complicated things. The number of visual elements cannot possibly be too high. And the application needs to be keyboard driven which I find to be a huge ergonomic/comfort/quality of life win. They are also generally faster and nimble, and expected to work without visual glitches.
And they work over SSH.
[OP] joshka | 10 hours ago
I grew up in the the 80s/90s and some of my first terminal GUIs were things like DOSShell and such prior to windows being a thing. Not a massive fan of going as far as building a full GUI, but I do want stuff to look good and get some of the usability stuff that comes from GUI research, this feels like a small step in the right direction.
GUIs definitely have their place. I much prefer them for coding agents for example (I say this as someone that worked on the Codex TUI).
There's lots of things that make sense as a TUI though, but this feels like it's one of those things that holds it back a bit. Raph (Rio maintainer) has a custom glyphs proposal that does a bunch of fun things as well. https://x.com/raphamorims/status/2120887890129388001
orib | 9 hours ago
Can you expand a little what distinguishes this from a full GUI, especially in light of projects like https://github.com/cyber-wojtek/waytermirror, which render Wayland into a terminal with sixels?
As far as I can tell, the main difference is the kind of styling that's easy to do, and the amount of fallbacks and variations needed if your terminal handles different features differently in termcap.
[OP] joshka | 7 hours ago
This is just a means to put lines between cells. Colored, segmented, siimple. GUIs are about arbitrary placement of components. Terminals are cell restricted. Yes you can build a GUI on a TUI if you want (by handling all the painting yourself), but this spec is not about that. It's agnostic about what you do with the borders. It fills a gap (literally). You can use that to make a GUI, but TUIs ain't GUIs.
orib | 7 hours ago
I'm not sure why they're not considered GUIs. As capabilities get added, the distinction seems like it's become negligible, and the main difference seems to be that the rendering is flakier and less capable.
[OP] joshka | 7 hours ago
A good answer to this might be to ask yourself how would labeling them GUIs make something clearer?
orib | 7 hours ago
They are GUIs. The main distinction, as far as I can tell, is that there's a little bit less setup to access them remotely, in exchange for a worse user experience. But that additional setup doesn't seem to be a fundamental limitation of the technology.
wrs | 3 hours ago
With all the visual protocol extensions like this, sixel, etc. it’s like we really want to reinvent the Blit terminal but can’t quite bring ourselves to cross that line.
zem | 47 minutes ago
it's still fundamentally character cell oriented, unlike a gui which is pixel oriented.
tstack | 6 hours ago
I develop a log file viewer TUI and have resisted turning it into a GUI when people ask. Part of the reasoning is that it needs to work over SSH. The other part is that I find GUI log viewers are filled with junk that takes away from seeing the actual log messages. I like to complain about datadog/grafana/etc because there is so much ornamentation and other stuff that you end up with a fraction of the screen real estate for the meaningful text. Ultimately, the TUI forces you to focus on what matters.
I also like to complain about TUIs that put borders around everything since it wastes precious space. So, this is nice to see.
[OP] joshka | 6 hours ago
Yeah, I can see how this would be pretty nice for lnav.
rafpast | 4 hours ago
You got me at useless. Now I want to recreate something like this using tmux and a terminal window manager.
chrismorgan | 10 hours ago
I really don’t understand why people keep on doing frames with gaps between them. It’s just ridiculously wasteful. In terminals, increasingly in window managers (I feel like it happened first as a tiling window manager gimmick under Linux, though maybe it was macOS, which was always really bad about wasting space in full-sized windows), even Firefox is now succumbing to this latest stupid design trend which has a terrible tendency to completely undermine content hierarchies.
Why this?
You don’t need the outer borders, and you can collapse the inner borders. Now, taking the same lines and columns, it can now even be ridiculously overspaced:
In this article: the panes example doesn’t feel like it needs extra borders and gaps, and the fallback behaviour isn’t entirely how you could reasonably expect it to be done: the header line could be integrated into the border (
┌─███████░░░░░░──────┐with text on the shaded areas). The chart example shows how it’s already abusing things (see how obviously it’s irregular); why not go fixing that with some addition? Or just rendering an image for the entire thing? You honestly might as well at that point.I would also just like people to stop trying to turn terminals into compositors; TUIs (as distinct from CLIs) are all kinds of problematic. The cellness of it all is a fairly extreme limitation, and we really should stop trying to force GUI-shaped objects into terminal-shaped holes. Keep it simple, generally try to limit yourself to stuff that would still work with a proportional font, and embrace the very limited colour palette you get given. Or else make a GUI.
Terminal emulation is already way too complex.
Yours sincerely,
A dyed-in-the-wool
vimuser(who would nonetheless like to be able to code in a proportional font without having to switch editor)
dutc | 7 hours ago
They make for superficial but attractive demos that challenge only uncontroversial or inconsequential preconceptions without demanding much else from the viewer.
In other words, you can put together something that looks kind of pretty (if you're just scrolling and don't occupy yourself with how you would use the programme being demonstrated); that looks very similar to something you're very familiar with (often, the demos involve recreating well-known GUI applications); that challenge the preconception that terminals and window managers are very separate and distinct things; that challenge the preconception that terminals are very obscure and difficult-to-use-things; that reässure the viewer that the purported complexity of creating, maintaining, packaging, or distributing a GUI may somehow be avoidable (after all, creating a “CLI” is so easy, it's where most introductory educational materials for programming start!); but also do not challenge the viewer to consider that to create an interface of high utility, there is an unavoidable and often very significant level of effort required (irrespective of the interface medium); and do not challenge the viewer to consider the serious gaps in their own knowledge (e.g., that, despite their years of experience using CLIs, many don't even understand how to design a good CLI of any moderate complexity†!)
† Seriously, most corporate CLIs are so preposterously bad, I wonder what they're even teaching people in school. It's a marvel when you run across one where the author considered, even fleetingly, “maybe we could read (line-delimited) input data from
stdin…?” Frameworks made this worse. With LLMs, there is no hope left. (Median LLM CLI design is atrocious.)In the era where creating demos required significant effort, we'd often marvel at what someone could create, and our attention would move on before the discussion would ever move to considering “is this thing actually useful?”
A friend of mine recently used an LLM to quite faithfully recreate the Bloomberg interface for financial data analysis. They didn't write a single line of code. It took about a weekend of work. Five years ago, this would have gotten them an unending stream of job offers. Today, instead, they got a bunch of social media posts… and a few days later, no one cares. Does the thing look very slick? Yes. Does it actually work? I guess? I don't know if anyone on social media even installed it. Does it do anything better than a Bloomberg terminal? Who knows? Is it competition for Bloomberg users? Probably not. Is there anything we can learn from their code, their design, their effort? No.
Setting this aside, your underlying supposition—one which I share—is that the various interface media (in this case, terminal-based vs window-manager-based) are sufficiently distinct that their design demands specific effort. An interface design that works in one medium will not “fit” in the other. Designing for a GUI should be very different than designing for a CLI or TUI.
If we investigate more closely, it's pretty clear that there are extremes where this assertion is obvious true and where this assertion is not obviously true. That is, on one extreme, we have programmes like, say, (the simplest version of)
topwhich probably wouldn't look very different as a GUI. At the other extreme, we have CLIs, and I don't think I even need to name an example to help conjure a vision of a workflow that is impossible to reproduce as a GUI. Somewhere in the middle are TUIs, which I think are on unsteady footing, though I think terminal protocol extensions (such as those proposed in this post) are actually mostly harmless.As you note, TUIs seem to demand a different design approach than GUIs, as a result of their cell-orientation and other related fundamental limitations. For example, because cell size is uniform, all graphical elements are uniform, and because “zoom” operates at the terminal level, we don't have dynamic resizing; therefore, your terminal window is generally sized and zoomed to the cell-size of the least important text in the interface; therefore, your terminals
$LINESand$COLUMNSare always too few; therefore, we're often cramped, wanting for more space, and sensitive to extraneous whitespace like border padding.I agree completely that a direct consequence is that visual style must subsequently adapt to these limitations to produce useful tools that are not simply demo-ware. From this perspective, the terminal protocol extensions proposed by this post would actually be very useful; however, it's probably fairer for the author to include as comparison a fallback mode of their demo programme that eliminates the visual styling. (This is basically what I would do, if I were writing such a programme: use all-edge borders more freely in the presence of the protocol extension and fallback to separating-edge borders or no borders in its absence, not just because it will likely look nicer and be less wasteful of space, but also because it will minimally inhibit naïf cut & paste.)
Similarly, as you note, it's true that TUIs are almost always a clumsy and discordant cramming of GUI metaphors into a foreign medium. However, I don't think that TUIs have to be this way. In fact, I suspect that there may be as-yet-undiscovered metaphors for TUI operation that provide a materially better interface to users than a CLI or GUI. That is, rather than considering the TUI as somewhere between a GUI and CLI, I suspect that the TUI may be it's own unique, distinct paradigm that has its own unique, distinct way of being operated. I don't know if there are many applications whose most effective interface is manifested in this medium, but I am fairly certain there are at least some.
Personally, I have recently been exploring the idea of programmatic, “non ad hoc” terminal multiplexing as an avenue for exploring this space further, and I think there's utility in this, but it's not clear whether there is really that much novelty, and I actually kind of doubt the idea will prove to be that revolutionary (but, still, probably very useful!)
[OP] joshka | 7 hours ago
Yeah, that's in there already - press b in the demos or just run it in a terminal that doesn't support this - i.e. all of them. the screenshots inthe article are show the fallback and note the problem.
[OP] joshka | 9 hours ago
Definitely not a necessary part of the spec - more something that I prefer on this and to demonstrate it in comparison to the existing solutions - the space makes it more clear there. But the thing about text is that words inherently need spaces between them to be readable. And TUIs exist generally in this weird text heavy, multi server / OS, keyboard focused, type heavy where GUIs aren't quite appropriate and people try to work around various shortcomings in the best way possible. Often the idea 'use a gui' is just not a relevant answer to the problem in the same way as why not use the vim gui isn't an answer for you.
There's a bunch of example TUI apps on https://ratatui.rs/showcase/apps/ that show various versions of what people tend to do in the terminal. These tend not to be the ones that I was saying were the problematic ones. But I'm sure they'll annoy your border sensibilities.
Unsure if you've posted something similar on hn a while back or if that was someone else, but I agree with you generally. I push back a bunch on bland boxes and borders apps a bunch in feedback
[OP] joshka | 9 hours ago
I just added a small collapsed version to the sample Ratatui app. Screenshots are in https://github.com/joshka/ratatui/blob/joshka/cell-borders/CELL-BORDERS.md#screenshots
Press
c(or start it withTILING_PANES_COLLAPSED=1) and the panes sit edge to edge: no outer border, one shared line between neighbours, ┼ where they meet. With box drawing, every shared line still costs a row or a column. With cell borders, the line sits on the cell edge and the text keeps the whole pane.The thing you'll notice is that the color of the border has to be owned by one of the cells on either side of it, so the approach here where borders are between cells neatly solves that problem
zem | 45 minutes ago
counterpoint: the most popular cell-oriented user interface out there is the spreadsheet, and cell borders have been a valued part of the design forever.
skulk | 7 hours ago
Ghostty is starting to remind me of Chromium; a place where new standards for a platform are unilaterally inserted and by which others are pressured to adopt due to popularity. I don't want to end up in a world where 90% of "TUI" apps actually require ghostty and will not render reasonably in any other terminal.
[OP] joshka | 6 hours ago
It's just where the energy is right now. iTerm2 and kitty have previously been places where that has happened a bunch in the past, xterm before it. Ghostty is different because of the rather unique nature of Mitchell doing a passion project combined with the LLM hockey puck nature of software development capacity and a need of people to massively parallelize command line stuff generally due to the same need for tooling. We're in a bit of an AI gold-rush era if you look at it that way.
I don't think that's a bad thing unless Ghostty were closed source, but it's MIT. You can rewrite it in rust if you want it (I've done this). Implement your own stuff on it if you want to (this too obv).
I also implemented this originally with Rio - same level of difficulty generally, and Raph has been pretty supportive of doing something with it.
I posted it on the Ghostty discussion because it feels right to get it in a real world terminal that many devs are gravitating to. Happy to post this other places too for it to be seriously considered as a proper option. But if you look at the recent OSC7501 stuff and how fast it went from Ghostty spec to implemented in a bunch of other places it's worth considering treating it as a place to start conversations around this sort of thing
dutc | 5 hours ago
I feel similarly ambivalent.
Ghostty is a fine terminal emulator (but I haven't tried all of the new ones, though I do also like WezTerm… and I should really try kitty again, since I had a really nice time meeting its core developer at PyCon India, who is really a lovely person.)
libghostty is extremely useful. As part of some background research, I was looking into the most minimal terminal multiplexer and collecting short examples (similar to the list of X11 window managers with <10k lines of code.) I intended to use these as a starting point for developing my own ideas; however, I abandoned this approach after creating a simple demo in Zig using libghostty. In fewer than a couple hundred lines of Zig code, I was able to create some very complex proofs-of-concept on top of the libghostty state machine (which is both easy to use and fairly complete.)
However, I would love to see more competition. libghostty is useful and good, but I think it's possible to create a better library for the underlying state machine—better from a performance, code quality, and design perspective. Furthermore, there's still a lot missing from libghostty, namely supporting functionality. That is, the proofs-of-concept that I was able to create in a couple hundred lines of Zig could have been even shorter, if I did not have to write some minimal helper libraries around the edges of the state machine. (To be fair, some of the helper libraries cover gaps in the Zig standard library—e.g., conveniences around system calls like
fcntlorioctl…) In fact, there may be even be a way to design the state machine API such that we can address complaints about common tools like terminal multiplexers.It's hard for me to judge the risk of a monoculture evolving around Ghostty. On the one hand, Ghostty is “where the action is,” and we shouldn't extrapolate too much from this. On the other hand, there is a pervasive feeling that programmers have become hesitant to invest in creativity, novelty, or design, because so much work can seemingly be accomplished without such cost. It's very hard to predict what the consequences of Ghostty development being pulled into the efforts of a start-up company developing what appears to be LLM tooling.
We know that consolidation can occur very rapidly in some circumstances, and they look like those we currently inhabit (e.g., your coworker whose argument is “well, that's what they're trained on,” when advocating against adopting new technologies,) but diversification can also occur very rapidly in circumstances that also look like those of the day (e.g., your other coworker's counterpoint that the bulk of the tedious effort involved in adopting some new technology can be done at very low cost.)
Terminal emulators have historically evolved very slowly, and this conservatism obviously has upsides and downsides. Many of us have come to terms with or have found coping strategies to mitigate the downsides, so we experience the conservatism as mostly a positive thing, preserving a useful, working environment. (As another comment here states: “terminal emulation is already way too complex.”) This more rapid evolution may seem disconcerting, but I think it's worth considering the goals of the kitty terminal protocol extensions:
Considering this, I think there's a case to be optimistic. If the evolution of the terminal protocol is as deliberate, as considered, and as thoughtful as this goal suggest… then maybe we'll be okay?
[OP] joshka | 4 hours ago
I'm working on something for that specific point, in Rust, every terminal spec, async request reply on queries, with proper timeouts, etc. Slowly as a background sleeper project when I have tokens and attention in sufficient quantities to burn.
Ayman Bagabas is also doing something similar with uncurses.
philocalyst | 2 hours ago
I believe the best work in this regard is with https://github.com/pg83/shitty and their implementation of the state machine in https://github.com/adrian-thurston/colm-suite, which if you see it purely as just that, should theoretically optimize it into ideal form
davidg | 2 hours ago
If you were to level such a claim at any terminal, I think that terminal would be Kitty: Kitty Graphics Protocol, Kitty Keyboard Protocol, multiple cursors protocol, drag drop protocol, etc, etc, etc.
ekuber | 7 hours ago
As restrictive as using
ASCIIUnicode art for drawing minimal outlines in terminal output, they have one big benefit. This cell border feature has the same drawback as leveraging colors for differentiating sections of the output. It breaks copy/paste by losing semantic info that might be needed.Looking at something like rustc's output, we could make the gutter where the line numbers are be one to two cells smaller by using a different background color, but then copying that or using NO_COLOR would make the output no longer look as easy yi glance.
For TUIs that drawback is less pronounced because most people don't expect to be able to copy the app's output, and the app can detect that it is in NO_COLOR mode and change the rendering.
[OP] joshka | 6 hours ago
yeah, there's definitely going to be downsides on this. Even doing alt mode vs normal wrapping mode in TUIs can be a problem for copy paste, as you get hard lines instead of soft. This is why e.g. lnav has a keybind to turn off all chrome and spit out the screen to the terminal as is.
I wouldn't suggest using this in non TUI contexts most of the time.
That said, it's possible that the terminal could also handle how to present this when copying and this becomes implementation detail rather than an actual problem.
ThinkChaos | 7 hours ago
I like the idea!
The log example's borders touch the text which is looks pretty bad IMO, and might make reading harder depending on the language.
I wonder if the protocol can mandate a visual separation.
[OP] joshka | 6 hours ago
yeah, there's various bits I'm not 100% happy with and this is one. I think I'd like to consider this maybe as expanding out from the text somehow into the surrounding cells, that might help this a bit better. That way you still lose the next cell over but can have a natural padding area that extends the bg color automatically or something like that.
andypea | 8 hours ago
I love this!
Does it fail gracefully in terminals without support and just not render the lines?
[OP] joshka | 7 hours ago
Yes. assuming the terminal is well behaved. As a simple test, both the Ratatui apps degrade fine in tmux under terminal.app if it's any indication of things not breaking hard (notoriously a painful combo). The detection logic in the spec is just normal stuff you'd expect.