[flagged]
Stop Making TUIs
531–540 of 579 posts
Re: Stop Making TUIs
#532The 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…
Claude Code should be heavily sandboxed to be used safely. Are you advocating requiring a gfx stack in the sandbox just to use Claude Code?
Why would that be?
Re: Stop Making TUIs
#533Earlier quoted context omitted.
What you're comparing is really "keyboard-driven" via "mouse-drive". A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.
Yes, but GUIs are by default mouse driven, very rarely one can see a keyboard driven one (I haven't seen any). And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).
Keyboard-driven GUIs belong in the realm of a lost art called "accessibility", which enabled people with motor issues (amongst many others) to use applications without a mouse.
FWIW, most of Windows XP's utilities and included software was perfectly usable with a keyboard alone.
Re: Stop Making TUIs
#534Maybe on macOS you have great APIs, libraries and toolkits for making high quality GUIs, but if you're wanting to write open source software or target open source platforms, your options are limited and poor. On the Linux/BSD side, most toolkits are of not great quality, you'll inherit all sorts of subtle bugs and quirky behaviours. Most of the software that's of _great_ quality doesn't use the toolkit, but interface…
Use Qt or Flutter
Qt is fully of bugs on Wayland, some of which are unfixable because the API makes guarantees that are impossible to uphold. I've reported a few issues upstream where there's no apparent path to fixing them (after years), and have reported countless bugs to applications which are just a bug/incoherency in Qt that can't be fixed.
Flutter is an absolute nightmare to install and work with. Even now the few bleeding-edge distributions where it's available are lagging behind many releases because of the pain that it is to maintain it. I don't want that level of pain as a pre-condition to building my software.
Re: Stop Making TUIs
#535Earlier quoted context omitted.
> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy…
”GUIs always look bad outside of the "main" platform.”
I think this is slightly wrong in two ways.
i) If you want platform native then reimplement the gui on every target platform. It’s as ”simple” as that.
If you need to ship to multiple platforms then preferably you need lots of plarform specific engineering in any case.
”I just want my hobby tool” scenario likely does not require cross platform support unless there is market for it. I mean rather than offering the tool on multiple platforms it should be offered on multiple languages first, perhaps. As soon as you are not writing the tool for yourself we are talking markets and distribution. Likely most people can chill out and just implement the gui for themselves (and not even publish it in githubb).
ii) cross platform quick-and-dirty way. Without screenreader support, multiple language and glyph support etc. Game ui:s look the same on all platforms. Websites look the same on all platforms.
There is place and time for deep ui engineering that respects the _critical_ cross platform issues like accessibility (screen readers etc) and different languages and scripts.
And then there is the situation where you want just few images to click. The latter is vastly simpler, fast and fun. But harder to convert to a professional quality gui experience. For small tools and MVPs this sounds like a fair tradeoff.
Re: Stop Making TUIs
#536Looks like the sagemath UI he mentions is here:
Re: Stop Making TUIs
#537I guess the author isn’t in ops. And that’s okay.
The whole point of a TUI is that it can operate under no-GUI constraints.
I can SSH to any server and use a TUI because SSH can handle that. Running an entire GUI and setting up VNC/RDP would be horrendous by comparison.
Alternatively, a TUI can be a part of an interactive CLI command where it maintains context to your CLI session. For example, I have a tool that helps wrangle AWS accounts and regions where the CLI momentarily drops into a TUI to help pick between regions and accounts if not already specified in environment variables. If I had to type all that out every time it would be very annoying. Hitting some arrow keys or searching with a few letters beats the CLI experience, and a GUI experience is not possible.
Re: Stop Making TUIs
#538Hard 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…
I don't use TUI when I can avoid it. I happily use CLI apps, or GUI apps, but TUIs are not here, not there. They lose all the appeal of CLI apps, while getting some weird text interface instead of a polished GUI library and all the possibilities that you can get from rendering pixels, not characters.
When I moved from DOS to Linux, I chuck away TUI file managers and switched to pure CLI and never looked back. I could use GUI file manager, there you can really use mouse, without that jumpy-movements it has in TUI apps. But I wouldn't touch Midnight Commander or whatever.
I tried to run emacs in a terminal. Emacs' support of GUI toolkits is very cumbersome thing. But guess what forced me to abandon this experiment? Emacs is keyboard-driven, and terminals have issues with some keys, while GUI apps can deal with virtually anything.
> If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different.
Try egui. I really like it. I'm not sure how much it is cross-platform though, hadn't tried it outside of Linux, but it is really nice. Or if you are an elm-purist then iced might be your choice. Iced lacks on widgets, it has just some basic ones, and if you need something to render a 2d-plot, then you are on your own.
Re: Stop Making TUIs
#539As a ratatui library maintainer, NO - please don't stop making TUIs ;) As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents. I agree with the article that the terminal is an odd…
> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
BearLibTerminal might be something on this line, although its purpose is mainly for developing rougue-like games. It simulates a terminal in a GUI with a high-level API
Re: Stop Making TUIs
#540Earlier quoted context omitted.
gtk1/gtk2/gtk3 code will require you shipping gtk(version) on modern linux, not all distros have the legacy libraries. Apple deprecated carbon (which was a thing when gtk1 was around). I don't think you have an option for this on their ARM hardware. QT1->N code has the same problem, the older libraries are not shipped on most modern linux. I do absolutely understand if you're going to do static compiles, that can wor…
Carbon was released in 2000 and final release was in 2019. Cocoa, correct me if I'm wrong, was released in 2005. That's 14 years to learn it. Not like you knew Carbon when Cocoa came out because there were like 10 developers making Mac OS X apps before 2007. y'all are slow learners if that's an issue for you, but React doing major breaking changes at least once a year is totally fine.
you miss the point entirely bro.