With no code-signing configured, each platform behaves differently: macOS Gatekeeper blocks the app immediately. You'll see either "TUIStudio cannot be opened because it is from an unidentified…
With no code-signing configured, each platform behaves differently:
macOS
Gatekeeper blocks the app immediately. You'll see either "TUIStudio cannot be opened because it is from an unidentified developer" or "TUIStudio is damaged and can't be opened" on newer macOS after quarantine flags the binary.
To get past it: right-click the .app → Open → Open anyway — or go to System Settings → Privacy & Security → "Open Anyway".
Windows
SmartScreen shows "Windows protected your PC". Click More info → Run anyway. Less fatal than macOS, but still alarming to non-technical users.
Linux
No such gate. dpkg -i TUIStudio-amd64.deb or double-click in a file manager — just works.
Read the original article
Comments
By voidUpdate 2026-03-1314:431 reply If you're going to put a video demo on your main webpage, can it have play/pause and a control bar? So I can actually skip to a part I want to look at. Here's the actual video: https://tui.studio/screenshots/video.mp4.
Also, how does this handle terminal resizing? Are there options to anchor elements to the left/right etc, or will narrowing the terminal window just make everything fall off the side, or worse, all the text wraps?
You can right click on it and choose "Show controls", at least in Firefox.
By voidUpdate 2026-03-1315:041 reply Oh, that's odd, it didn't show up on chrome when I first tried it, but it does now. I was wondering how they'd managed to hide the video context menu
It's probably just <video> element without "controls" attribute.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
> controls
> If this attribute is present, the browser will offer controls to allow the user to control video playback, including volume, seeking, and pause/resume playback.
Edit: I misunderstood, you are asking
> how they'd managed to hide the video context menu
Not sure, but it works in FF for me
By voidUpdate 2026-03-1315:16 Its entirely possible I did something to it accidentally that made the context menu not work properly. I had the dev tools open to pull the actual video address when I right clicked, so I might have messed something up. Or maybe the devs are secretly looking at the comments and fixed it between me and you trying :P
By sam1r 2026-03-1315:19 It won't let me reply to parent's child comment, but i wanted to say:
That is what HN is for!
This is nonsensical, there is nothing textual about the UIs being shown here. It doesn't stop being a GUI if you have a 1:1 representation of the concept within character cells.
The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the UX expected for GUIs, it has become a GUI larping as a TUI.
> But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the UX expected for GUIs, it has become a GUI larping as a TUI.
Hard disagree. Borland TurboVision [0] was one of the greatest TUI toolkits of the DOS era, had all of these:
> Turbo Vision applications replicate the look and feel of these IDEs, including edit controls, list boxes, check boxes, radio buttons and menus, all of which have built-in mouse support.
Well, I can’t remember if it had tabs.
Vasellating. TurboVision was awesome, but it was pushing the boundary of TUI, which in my mind was great for moving hard copy to computer entered use case. To wit, hard copy on your right side, you transfer data to app without looking at screen, but just looking at hard copy, remembering when/where to hit return key, maybe tab for prior field, stuff like that.
But hey, if the screen is drawn 24 x 80 with extended ascii, it's TUI. And man, loved the "absolute" keyword in turbo pascal. Instant screen writes when writing to a 2 dimensional array.
By weinzierl 2026-03-1319:49 I don't remember "absolute" but I sure do remember "gotoxy" and it rhymes with boxy, yeah, you won't convince me otherwise.
By dec0dedab0de 2026-03-1313:552 reply It's a TUI if it uses text to build those elements.
You can be effective and powerful in any kind of interface, Just like you can be ineffective and weak in any kind of interface. People like TUIs because they're cool, and work over SSH.
By jvanderbot 2026-03-1314:241 reply Yes. A TUI runs in a text session. A GUI runs in a graphics session. A terminal emulator emulates a text session in a graphics session - and allows you to run TUI/CLI tools. This is apparently controversial?
> TUI runs in a text session. A GUI runs in a graphics session
What do you mean by this? I have never heard these terms before. I can launch and interact with a GUI from a text application, or a text application from a GUI.
It makes far more sense in the context of effectively a remote session or dumb terminal serial connection. Your "terminal" application is only emulating a text mode environment inside a gui, typically... you can ctrl+alt+F2 - F5 in a lot of Liknux's to switch to a terminal session if you want, but that's not what people tend to actually use.
Beyond this, without remote X properly configured, again, most don't and probably shouldn't.. you aren't running remote gui applications over an SSH session. Richer TUIs were pretty common in ye old days of DOS and other OSes before rich GUIs become the norm. DOSShell, Edit.com, etc. The IDEs of days past and Word Perfect even. These all interacted with Mice and were considered the norm. The features that allow this over a remote terminal today are pretty great IMO, the harder part is properly handling window sizes/resizes, etc.
With graphical extensions, there are even nice app explorers with image previews via TUI. It pushes the boundaries. For that matter, I often wonder what could have come with RIPscrip/RIPTerm if the leap to web didn't happen the way it did...
I think the single hardest part of TUI is dealing with wide characters and secondary fonts for color emojii that don't quite render in 2 spaces completely in a lot of termianls... it makes the line drawing harder too.
By zahlman 2026-03-1318:39 In the Linux world, your GUI is built on a stack of separate programs. At the bottom is the "display server", such as X11 or Wayland. One of these needs to run to have GUI windows (or a full-screen background) at all; otherwise the screen is just covered by 80x24 terminal, and even if there were mouse support there would be nowhere to click or drag to change that. Without the display server, you are in a "text session". It's relatively rare to do this locally nowadays, but Linux still adheres to the highly modular UNIX philosophy.
Your terminal windows (whether that's "Terminal" or "cmd.exe" or anything else) are still fundamentally graphical programs that emulate such a text session.
By robotresearcher 2026-03-1316:47 Is it character mapped, designed to run in a tty terminal? TUI.
Is it pixel or vector mapped, designed to run in a graphics terminal? GUI.
Of course strictly speaking TUI is a subset of possible graphical user interfaces, but the term GUI was coined to denote interfaces other than the already-ubiquitous text terminal interfaces.
TUIs have since absorbed GUI interface elements like buttons, checkboxes, and even pointer input, which I think is causing the terminology complaint here. Classical TUIs like Norton Commander are more about keyboard input and navigation. But being text-mapped is the identifying feature of a TUI, I think most people accept.
By chrisshroba 2026-03-1315:52 Sometimes your system doesn’t have a graphical session, like a raspberry pi with no x server running, or a cloud compute instance I’m ssh’ed into, or a docker image running on my laptop. Sometimes your system doesn’t have a (particularly usable) text system, like a work computer that disables the terminal or a family member’s MacBook who doesn’t have the time or space to install XCode terminal utilities to be able to use things like brew install.
My point is that it’s not a given that having one means you have the other.
TUIs are wonderful for the first case.
By riquito 2026-03-1315:49 Perhaps he's thinking about "console" / "display server" but the lines blur fast (e.g. you can run GUI in linux console with framebuffer with some limitations)
- https://en.wikipedia.org/wiki/Linux_console - https://en.wikipedia.org/wiki/Windowing_system#Display_serve...
By dec0dedab0de 2026-03-1316:07 It feels like a reference to DOS graphics mode.
By reaperducer 2026-03-1314:133 reply It's a TUI if it uses text to build those elements.
No. All you've done is make a low-resolution GUI.
TUI means "Terminal User Interface" or "Text User Interface"
A GUI that is built with Text, and intended to be used in a Terminal, is what a TUI is, colloquially AND definitionally.
What do you think qualifies as a TUI?
This is a pointless semantic argument.
Of course you can use the primitives of TUI, especially with mouse support, to reproduce a large amount (if not all) of the standard GUI interaction paradigms.
But it's bizarre, and missing the point from a UX perspective.
As an extreme example, we can imagine a program that displays the borders of a 40x15 "window" in the middle of a console, with box-drawing characters, putting a "close box" in an upper corner, with text like "File Edit Help" in the top left. We can imagine it responding to a click on the "File" text by popping out a "menu"; we can imagine a drag starting from the "title bar" causing the window position to be update (and the entire terminal window redrawn).
A lot of those kinds of functions, ironically enough, might make sense for a TUI editor implemented as a TUI (except the "windows" might just be understood as panels where the ultimate program displays parts of its output). But as an emulation of GUI windows, it'd be a strange, impractical novelty.
By StableAlkyne 2026-03-1319:13 What's with the purism? It's just a term used to differentiate one way of making a UI from another. Who cares about what is practical when you're just trying to give a thing a name.
Even in your example, it's pretty clear cut. If the window is built with text and served in a terminal emulator, it's a TUI. If you build it with a graphical framework that now needs X11 or whatever, it's a GUI.
This is just needlessly pedantic.
By reaperducer 2026-03-1314:581 reply I've been using TUIs since PR1MEOS mini-mainframes in the early 1980's, I know what I'm talking about.
The issue is not the text. It's the WIMP interface.
By mikkupikku 2026-03-1316:08 Define TUI. I'm genuinely curious what it means in your context.
Yeah, that's the point. Why did you think you needed to say it?
It's a GUI that works over SSH. There is a very valid use case for that.
I assume his point is that making stuff that assumes a mouse makes for a bad text-based UI. Absolutely fine if everything is controllable via the keyboard, e.g. if the tabs were labelled F1-Fn and they function keys switched them, or they had an underlined letter and Ctrl+letter switched focus to it, or whatever.
But if this thing requires you to just tab a lot through lots of pointless and rarely used fields to get to a "button" so you can activate it, because it's really all designed to be used with a mouse, then it's a bad text-based UI.
There are some incredibly good text-based UIs around, some going back to mainframe stuff from the 70s. Most of them are optimised for speed of control via keyboard rather than for looking pretty. Almost none of them would be quicker to use with a mouse.
By dec0dedab0de 2026-03-1316:181 reply absolutely, but it's still a TUI. Just like if you made a GUI that didn't have any mouse support and needed all keyboard shortcuts, it wouldn't stop being a GUI.
By ralferoo 2026-03-1317:55 TBH I've always hated the backronym TUI anyway, so if TUI includes things that require mouse input, then maybe we can go back to using "text-based UI" for things that only require a keyboard like we used to 30 years ago.
By jandrese 2026-03-1316:50 Would you say old DOS applications like Borland's Turbo series of compilers were not TUIs? They ran in the console but had menus, mouse support, dialog boxes, etc...
How about those text games that used ASCII art and you typed in commands like "look" and "go north"?
I would say using text mode is the primary requirement for a TUI. The other requirement being some kind of human-machine connection, IE a User Interface.
By PurpleRamen 2026-03-1314:05 > there is nothing textual about the UIs being shown here.
Well, except:
> a 1:1 representation of the concept within character cells.
TUI is build from text, and living within its constraints and what it's engine (usually the terminal) allows. GUI is build from graphics, and has basically a pixel perfect control of its own. This is a very notable difference, especially at the time when these terms were coined.
> TUIs are generally built for effectiveness and power
No, this is a result of different architectures and their constraints.
> But once you start adding mouse clickable tabs, buttons, checkboxes etc. you
TUI and mouse are predating the GUI (more or less). We had them already 40-50 years ago at the dawn of interfaces. We are now just moving back to them for practical reasons.
The UIs are text only, so they are textual. Modern TUIs may support mouse events. That this tool can export to several TUI frameworks is evidence that these UIs are indeed TUIs, even if not the most traditional.
“Modern TUIs may support mouse events” hah! They already did in the 80s…
Yeah, remember good old Norton Commander (https://en.wikipedia.org/wiki/Norton_Commander) - not that newfangled clone Midnight Commander, the original? Or the Borland text mode IDEs (https://ilyabirman.net/meanwhile/all/ui-museum-turbo-pascal-...), complete with windows, menus, buttons, scroll bars, file dialogs etc. etc.?
By jgilias 2026-03-1315:31 Oh boy, that sent me down the memory lane hard. I also had to Google “Volkov Commander”, as that name sprung to mind immediately too.
> That this tool can export to several TUI frameworks
It clearly cannot. Have you even tested it?
This? Alpha notice: Code export is not functional yet. We're actively working on it — check back soon.
Exactly, don't know why people are acting like actually makes TUIs, it's just a rough mockup of a TUI for now, with a convoluted figma-like UI.
I guess the headline and website was enough to get all these upvotes. Quite disappointing as someone in the early stages of making a TUI tutorial myself.
I've been juggling some BBS related projects myself that involve some TUI work over raw and web sockets that I've been working on... It's definitely a fascinating space and there's been a lot of relatively recent activity in the space.
By elxr 2026-03-1316:20 > and there's been a lot of relatively recent activity in the space.
100 percent agree. I personally love what the openTUI folks have been up to. As weird as this might be to say, we're still in the early, early stage of TUI adoption.
By jvanderbot 2026-03-1314:261 reply No, a text-based UI is not sufficient. It must also work in a text-only session e.g., on the CLI over SSH.
By 627467 2026-03-1314:53 Do UIs exported from this tool not worknon CLI over SSH?
By Trufa 2026-03-1314:43 I think your comment is nonsensical.
Zellij among is a great example, I can do everything with my keyboard, but every now and them I'm already with the mouse and just click a tab or pane, no functionality lost, just added, why the need to make a cutoff philosophical/semantic hard argument?
By h3lp 2026-03-1317:39 Good insight, but if you discount the visual elements (tabs, buttons, etc), you're limiting TUI to CLI, and I think that's unwarranted. The value proposition of both TUI and GUI is two-fold: you see the available action options, and you see the effect of your actions. So, yes, TUI and GUI _are_ closely related: who cares whether we're displaying pixels or character blocks.
Unfortunately, they are often artificially differentiated by the style of the UX interaction: TUIs promote the keyboard actions, and GUIs prefer mouse without corresponding keyboard shortcuts. Unfortunately for GUIs, their designers are often so enamored with WIMP that they omit the keyboard shortcuts or make them awkward. I hate it when, even if the ACTION button is available by keyboard traversal at all, it requires some unknown number of widget traversals instead of being one tab away.
Since the keyboard is almost always used for the textual data, it makes sense to me to always enable it for command execution. Well designed GUIs and TUIs provide both WIMP and keyboard UX, which sadly is not the norm today, so here's my vote to make them larp for each other more.
By criddell 2026-03-1314:18 Would you make the same argument for classic UIs created with things like Borland's Turbo Vision framework? It's generally known as a TUI framework (including by Wikipedia).
By JodieBenitez 2026-03-1315:001 reply I like TUIs keyboard-centric. Mouse can be a plus, but it should never be necessary.
By tracker1 2026-03-1316:03 That's fair... I feel that way about GUIs too in general though. Everything should be keyboard navigable and reasonable control flows. Tab and arrows, etc. Should be able to control focus and selection (enter).
I admit I don't always pay the most attention to it, as the UI components I tend to use do a good enough job of this. But I'm usually pretty consistent with it.
By theowaway213456 2026-03-1313:155 reply You can tunnel a port over SSH and get a web UI locally, though it's not commonly done. I feel like more people would actually do this if tunneling a port was just ever so slightly easier (like, you're already SSH'd into a box, then you run a command, then you somehow automatically get a tunnel for that command's UI port plus a local browser window open to the page)
While in an SSH session, press enter, then type tilde and capital C (enter ~C) and you can add command line options to the current session. To add a port forward from your local 8080 to the remote port 80 without closing the connection, do:
enter ~C -L 8080:localhost:80By Tepix 2026-03-1315:57 Thanks. This could really benefit from a TUI!
By zimpenfish 2026-03-1313:57 That is a neat trick. Added to the list.
(Ultimately unhelpful though because I use mosh everywhere these days and that doesn't appear to have anything fancy like this.)
Maybe it's just still too early in the morning yet, but what is the significance of hitting enter first?
By jasongill 2026-03-1314:51 SSH expects the escape sequence (tilde) to be the first character on a new line; since backspace is sent as a character, you can't just backspace over something you've started typing and then press tilde to have it recognized.
Technically, you don't have to press enter if you've not typed anything (try it in a new SSH session - as soon as you are logged in, type ~? to get the SSH help output), but since the comment was about doing this during an active session without ending it, I figured noting that pressing enter first to be sure you're on a new line wouldn't hurt
I like TUIs because I run everything in tmux and I can just pick up work from wherever I was on any computer, phone or tablet.
By DesiLurker 2026-03-1315:45 share some good (easy on remembering keyboard & mouse) tmux configs. I usually struggle with copy pasting many scrollback lines from/to tmux. would love for my claude to be natively tmux aware.
I do this a lot but I'd still prefer TUI where possible. With too much visual content it isn't of course, but for many cases a TUI is much more responsive and much lower resource.
By surajrmal 2026-03-1315:08 I largely agree with you, but there are limits to what a tui can do well. If analyzing a flame graph or performance trace, web UI is a better fit. However, most things are not that.
By roywiggins 2026-03-1313:381 reply Even easier is just using an X server, if you have it set up properly you just need to run the remote app and the window pops up on your machine.
(I think terminal-based GUIs are neat just for fluidity of use- you can pop one open during a terminal session and close it without switching to mouse or shifting your attention away from the terminal. They can also be a nice addon to a primarily CLI utility without introducing big dependencies)
Yeah I love that about X. I remember in the 90s when I first figured that out. I was logged in from a university workstation into my home computer with SSH and I launched my mail client or something and I thought doh, stupid that will only popup locally.
Then colour my suprise when it popped up on my screen right there. Slow as molasses but still. Wow. Magic.
It's a shame Wayland dropped this. Yes I know there's waypipe but it's not the same.
> It's a shame Wayland dropped this.
It... really isn't. Like you said, remote X was barely usable even over an entirely local network. Most applications these days are also not designed for it, using loads of bitmap graphics instead of efficient, low-level primitives. So you end up being just one tiny step away from simply streaming a video of your windows. We have better tools for doing things remotely these days, there's a reason approximately no one has used remote X after the mid-90s. It's a neat party trick, but I don't blame the Wayland authors for not wanting to support it.
It is, there were tools like NX that made it entirely usable even latencywise. And these days we're really going more and more to remote computing.
In the time when wayland was invented it made sense because we did everything purely local. But now it's as outdated as X11 was in 2010.
And yes I still use it a lot. It works well. Networks have become a lot better and even most cloud compute I use is geographically nearby.
What made it slow back then was that I only had a 128kbit uplink at home. And the uni had 2 mbit for the whole computer science building :)
By pseudalopex 2026-03-1318:55 > In the time when wayland was invented it made sense because we did everything purely local.
People complained of no forwarding in Wayland when it was invented.
By cbm-vic-20 2026-03-1315:46 > one tiny step away from simply streaming a video of your windows
In the 80s/90s this wasn't feasible due to network latency and bandwidth, but it's pretty common now to do exactly this, with VNC and other remote desktop protocols.
Like what? X forwarding has pretty much always been the thing most likely to work for me and I haven't been able to find any equivalent.
The big obvious one is web-based tooling. Your information & settings are stored on a server and you use a web browser to view it via whatever device you're on. For more locally based workflows, we have networked filesystem protocols, automatic syncing between systems, that kind of thing. It's not a 1-1 equivalent of running a remote program and viewing it locally obviously, but it gets the same job done, in a much more useful & flexible manner than X forwarding did.
For example, the remote mail client usecase I was replying to is simply done with a webmail client today.
I don't really feel like web interfaces or syncing are really a substitute tbh, and I'm not sure how they're more flexible. ssh -> run -> gui opens, and the program itself doesn't need to be designed differently to work
> and I'm not sure how they're more flexible. ssh -> run -> gui opens
But this doesn't work on your phone, or on a Windows or macOS device, right? That's what I meant by flexible, X forwarding fits a pretty narrow set of usecases, while on the other hand keeping programs on the clients and data centrally located on a server allows for a whole lot more options for how to interface with that data.
(To be clear, nothing wrong with X forwarding! It's a cool tech and I'm glad you have a use for it! I'm just arguing that it's fine for Wayland to not try to support that kind of thing, because we've got other ways of working remotely now.)
By pseudalopex 2026-03-1318:48 X servers are available for phones, Windows, and macOS. X interfaces not designed for phones can be difficult to use on phones. But web interfaces not designed for phones can be difficult to use on phones.
There is not a web tool for every use. And web tools are not better for every use.
IIRC, it's not that secure though.. I'm really surprised people didn't do more things like send animated skulls to people's desktops.
By throwawaymobule 2026-03-1317:39 Waypipe looks interesting.
The main advantage of x forwarding for me was when I'd randomly need it and had nothing set up ahead of time. Hopefully it starts getting installed in distros by default eventually.
By marxisttemp 2026-03-1314:08 I'd rather use a TUI than a web UI.
Sure, but my point was that UX matters for TUIs. A TUI with a UX that fits its paradigm , again like lazygit, works great over SSH.
By papageek 2026-03-1314:47 Another justification could be simply some people like using them better.
By apitman 2026-03-1318:46 People don't build TUIs because they want to run apps in the terminal, they build them because the terminal happens to be the most portable app platform available.
By jandrese 2026-03-1316:47 I've been working with notcurses recently and it is a full TUI that handles mouse events just fine. Runs over slow SSH connections and everything. The nice part is that you can fully operate applications built on top of it with the keyboard if you so choose, the mouse is just a shortcut.
Sadly the project is not really in a usable state at the moment. The documentation is incomplete riddled with errors, the code has some pretty glaring bugs, and it's close to abandoned. It's a shame because you can do some really amazing stuff with it.
By jhbadger 2026-03-1316:01 You might not like this type of interface, but it is hardly "nonsensical". In the 1990s this sort of text-based GUI was common in DOS programs, such as Borland's "Turbo" languages and the original pre-Windows FoxPro.
By injidup 2026-03-1314:24 lazygit supports vim style keybindings and mouse click and scroll. I mostly use the key shortcuts but sometimes the mouse is useful. But i agree that a well thought out state machine that can be navigated through via keyboard is a dream to work with. Lazygit is superb. But this is not a distinction between TUI and GUI.
By temporallobe 2026-03-1318:21 Yes and no. Early DOS UIs had elements of TUIs and GUIs, and supported mice. Many old school greenscreen applications were like this too.
By BoredomIsFun 2026-03-1316:26 > But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the UX expected for GUIs, it has become a GUI larping as a TUI.
TIL that VIM is not cease being TUI the moment I type :set mouse=a.
Hot taking, LARPing and teenage angst (caused by generational gap with those has been using TUI since 1980s) is on your side.
By musebox35 2026-03-1315:31 My ancient boxed copy of Visual Basic for DOS 1.0 that supported mouse clicks on TUI buttons would have found your viewpoint quite offensive if it had any AI in it ;-) Oh boy, good old days.
By jvanderbot 2026-03-1314:211 reply The distinction is - if it runs over ssh (no x / graphics login) or on a headless machine - TUI
If it requires graphics login, even if it uses character layouts - GUI
IMHO the T/G is not for the display elements, it's for the type of session.
By tgv 2026-03-1314:56 Not to put too fine a point on it, but X11 runs over ssh just fine. No "graphics login" required.
By cmrdporcupine 2026-03-1315:181 reply Man, I've had so much frustrating just trying to copy & paste from inside a terminal running e.g. opencode or crush.
I think TUIs are neat, I guess. But I think these things have abused the concept extensively. They don't actually interact well with the rest of a Unix environment.
By throwawaymobule 2026-03-1317:41 Hold down a key (alt, I think) to prevent clicks.
By ram90 2026-03-1317:14 This is exactly the kind of passive aggressive attitude that is tolerated on HN that makes this place unbearable.
"This is dumb" - gets downvoted to oblivion. "This is nonsensical + a bunch of absolutely bs reasoning" - second most upvoted comment atm.
HN tolerates the appearance of quality discourse over the actual thing, and dealing with this dissonance in most comment sections is exhausting.
By ganelonhb 2026-03-1315:27 Reddit moment!
By whiteboardr 2026-03-1314:48 As a german, I say:
UIUIUI
By clickety_clack 2026-03-1313:512 reply Drawing a “nonsense” line between TUIs and GUIs is pretty arbitrary, it’s all pixels on a screen at the end of the day. People like the TUI vibe, and that’s a good enough reason to make and use them.
I love TUIs but one main reason for that is that they're keyboard centric. If I have to use the mouse it kills it for me, if both work then it's fine. I hope that modern TUI makers keep this in mind. What's great about the keyboard centric is that with a few keystrokes/shortcuts it's very easy to do repeatable work and takes less energy than hunting boxes to click on with the mouse.
By mikkupikku 2026-03-1316:12 TUIs aren't more inherently keyboard driven than well constructed GUIs. You can easily make a keyboard driven GUI that has all the shortcuts you'd add to a TUI. (Just don't let the "UX design experts" near it.)
I actually agree with that. And I enjoy the fact that TUIs are becoming popular. But there is more to it than just the 'vibe'.
By clickety_clack 2026-03-1314:13 The vibe might not be a necessary reason, but it is a sufficient one.
By mikkupikku 2026-03-1313:391 reply [flagged]
If you think the 'mouse-clickable' aspect is bothering me, you missed my point entirely.
By mikkupikku 2026-03-1316:19 The only thing you actually managed to complain about was clickable tabs, buttons and checkboxes. Besides that, what it exactly do you object to, the design vibes? The only reason to be making a TUI in 2026 is as form of personal expression, so your preferred design vibes are no more valid than the OP's.
By bonoboTP 2026-03-1314:38 That's the only concrete thing you mentioned. By that criterion, htop isn't TUI.
I really don't want my TUI's to look like GUI's rendered in low res. The appeal to me of a TUI is that it is built specifically to be a TUI, and that means eschewing complexity and detail, and favouring compact text.
> GUI's rendered in low res
That's literally what TUI's looked like starting from the late 1980s and throughout the 1990s... You have a pointing device, might as well make use of it to enhance discoverability.
By zahlman 2026-03-1318:52 This seems really reductive. Some UI paradigms work better at 80x24 vs at 640x480 (never mind whatever resolutions we have access to today). Or rather, the 80x24 text grid is using more pixels than that, but everything is aligned to that lower resolution, and that fundamentally changes what makes sense to do. Floating windows that can be dragged around to arbitrary positions? Terrible for low-res; classic for higher res. Dividing lines that split the screen into panels, and can be moved around a row or column at a time with a keyboard shortcut? Pretty much the opposite (enthusiasts of "tiling WMs" might disagree).
By m3kw9 2026-03-1316:01 Didn't they evolve from that because better graphics was better? Otherwise why not stay text if there is a huge advantage in all Text made graphics?
By duped 2026-03-1317:14 This is why I don't like TUIs at all, they're really bad at displaying complex information, handling complex interactions, and discovering how to compose those together.
