Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Making TUIs

sockpuppet.org

Post reply on HN
Print view View original

431–440 of 578 posts

Re: Stop Making TUIs

#431

Post by cavem0nkey »

You can shit on TUIs but macOS isn’t the panacea of GUIs. This really compromises the argument. In fact I’d argue it’s one of the worst platforms for GUIs.

Sure it looks pretty but it’s impossible to drive from the keyboard without mutant hands and savant level of memory for arcade combos. That means the entire OS relies on being able to drive the UI from a positioning device and thus you have to have the coordination to piss on an ant off a moving train. Which is terrible when the input devices are a touchpad, which varies so utterly frustratingly depending on whether it’s in the laptop or over Bluetooth. That and a mouse which is designed by a complete psychopath. That leaves you with third party options which require apps to not suck and they still suck. Scrolling on Logitech options anyone? Even LinearMouse can’t fix that shit.

Compare windows which works absolutely fine from any keyboard or any mouse and is discoverable and consistent. Also no mutant hands required.

TUIs are closer to windows than macOS. And that’s a good thing.

I did the last ten years on a mac and decided I was just hurting myself. Give me windows or a TUI. I notice Linux desktop environments tend to copy windows with respect to keyboard and discoverability too.

Re: Stop Making TUIs

#432

Post by wowczarek »

ricardobeat wrote: post #386

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

> If we had a cross-platform usable GUI framework

I could swear there once was a (n)curses or otherwise text based GTK+ implementation / backend. It didn't do everything of course, and this was, I don't know, about 2003-2007, but you could compile a GTK application and run it in the console.

I tried finding a link, but unfortunately could not, can't even remember the name, I only remember building a piece of software that way that did GUI or TUI depending on how it was linked.

Re: Stop Making TUIs

#433

Post by simianwords »

mihaic wrote: post #393

The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand. Every time I use Claude Code, I'm wondering why the hell I'm regressing to the level of a machine. I paste an image that I want fixed, and I don't see the preview of it. I can't cut or edit text somewher…

I have to agree with this. Ever since Claude Code released I always asked why it had to be a TUI but the sentiment I saw was that it was more powerful for some reason. I never bought that argument.

Now I use Codex UI which is miles better than any other tool I used.

Re: Stop Making TUIs

#434

Post by vikramkr »

chiph wrote: post #429
a2ff6eeb0 wrote: post #391

Earlier quoted context omitted.

GUI programs can also use the keyboard.

Depends on whether the devs included keyboard accelerator mappings. With the rise of "touch focused apps", it's becoming rare.

Sure but in this case we're the devs. We're in charge of that and would include them if we're making a gui instead of a tui and want keyboard accelerator mappings.

Re: Stop Making TUIs

#435

Post by grepps09 »

ricardobeat wrote: post #386

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

[dead]

Re: Stop Making TUIs

#436

Post by 63 »

ricardobeat wrote: post #386

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

When you're one of the people who finds TUIs inaccessible, "accessibility" isn't just a downside to be considered, it's table stakes. I think they're fine for one off toys for individuals and small groups, but if you're selling a product to the public, it ought to be accessible first and foremost.

Re: Stop Making TUIs

#437

Post by skapadia »

How about build whatever interface makes sense for the user? Doesn't matter if it's a TUI, GUI, speech interface, or some physically actuated / haptic feedback based system. Do what makes intuitive sense to the user and provides enough expressive power to get their job done without overwhelming them.

Re: Stop Making TUIs

#438

Post by bionade24 »

jayd16 wrote: post #418
boredatoms wrote: post #394

Earlier quoted context omitted.

A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this

That's an indictment of ssh workflows not GUIs. RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease. We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.

Of course there is, waypipe, ssh -X, wayVNC on a headless cage (or sway with appropriate config) session.

Re: Stop Making TUIs

#439

Post by goolz »

mihaic wrote: post #393

The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand. Every time I use Claude Code, I'm wondering why the hell I'm regressing to the level of a machine. I paste an image that I want fixed, and I don't see the preview of it. I can't cut or edit text somewher…

I honestly get better results out of claude at the command line than inside a GUI. Maybe I am just imagining things. But a lot of times GUIs are just graphical abstractions of TUIs. It is cruft that makes things visually easier and more appealing. That does not stop people from mastering TUIs and unlocking extra potential as they typically offer much deeper customization.

Once you go down this path, it is hard to go back. Very few tasks, apart from things like Photoshop and Revit, really require me to be at a GUI these days. And with MCP a lot of that is going away.

Re: Stop Making TUIs

#440

Post by jimmaswell »

bayindirh wrote: post #325
fschuett wrote: post #323

Earlier quoted context omitted.

> They don't need GPUs to render, megabytes of RAM to run They do these days, because you still need a terminal emulator and those are then basically GUIs in themselves. Ain't the 80s anymore :^)

I still have quite a few systems which doesn't have a GUI attached to it, and I access them via a pure console. Most, if not all these systems have Matrox G200 or similar low end 2D integrated graphics which are just there to see the text during boot, nothing else. I sometimes SSH from these systems to my own systems to use TUI or CLI tools. If I want to go a step further. We have a couple of real VT320s. Working at…

> We have a couple of real VT320s.

That's awesome, I have one too and I fell in love with it. I fixed up the old gif320 program to run properly on modern machines a while ago and made a C# port too:

https://github.com/ldyeax/gif320

https://github.com/ldyeax/Gif320Sharp/

How do you deal with modern programs not respecting TERM/LANG capabilities? I found even using man pages on my machine would sometimes result in the terminal getting caught up on some invalid byte sequence emitted from some unicode that snuck its way through or such.

I ended up writing a program I called VT320 Translator, or vt320t for the name of the binary, which in broad strokes runs your target program in a background terminal and sends curated updates to the VT320 while passing through keyboard input. (You can kind of approximate this with just screen and some other things but it doesn't end up being very good IME) This lets me do some neat things like translate unicode characters into DRCS (Dynamically Redefined Character Set) sequences that you can actually see on the VT320, use optimized heuristics for screen updates tuned to the exact hardware, etc.

At the core is a vtparse-based VT320 emulator that strives to be as accurate as possible with an accompanying diff generator from one emulator state to another. If you're interested I could get into more of what I've done here and even get the code onto my github - it's been private for a while because it's being used in an upcoming game demo but I could easily separate out the non-game-related parts that make up vt320t.

Post reply on HN