Live data from Hacker News

Stop Making TUIs

sockpuppet.org

561–570 of 580 posts

Re: Stop Making TUIs

#561

Earlier 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?

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 http://foo.wyrd.name/en:bearlibterminal

yeah, something along those lines - but more robustly defined.

Re: Stop Making TUIs

#563

Earlier quoted context omitted.

This is covered towards the end of the article.

I only see a bunch of references to swift (very much not portable), but I did skip the Q/A style section. I see he mentions portability, but still no mention of actual portable frameworks. The word "macOS, "apple" or "swift" appears ~7 times each. No mention to any other GUI framework other than ...a link to the bloomberg terminal website? I would find the title less misleading if it was "I like swift". Let say someo…

[deleted]

Re: Stop Making TUIs

#564

Earlier quoted context omitted.

> Textual Please, don't. One of the main benefits of TUI is being able to freely copy text, I hate opening Textual application and being dropped into this canvas like state.

A workaround is to use shift + mouse drag to enter terminal native selection mode. (Works in most terminals I believe)

That's fine until what you need to copy gets extra line-breaks inserted

Re: Stop Making TUIs

#565
post #117

Earlier 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.

Carbon and Cocoa changed a bunch of times, also React actually makes sense even though it also changed

Re: Stop Making TUIs

#566
post #343

Earlier quoted context omitted.

The advantage is that you can run it in a terminal... So in tmux, over ssh, etc.

Why or how is that an advantage over proper GUIs via some remote desktop protocol?

Latency. My home setup has a different number of screens vs the single virtual display on the headless workstation/instance. I don't want to deal with a Linux GUI shoved into my Mac via screenshare. Linux screenshare host is finicky in the first place. I do lots of stuff via CLIs anyway. I connect to multiple remote instances at once. All those reasons make it easier to SSH.

Re: Stop Making TUIs

#567
post #251

Agree with the rest of the comments here: keep making TUIs. Fully keyboard-driven, compact interfaces that live in my terminal with the rest of my CLI devtools are the best!

This makes me curious. What are your favourite TUI applications? The only one I use is Copilot (inside of a VM). ALl other applications I use are GUI/CLI/webapps.

Vim and Tmux. Does psql count too? I'm not really a fan of TUIs aside from that, most stuff is just CLIs.

Claude etc do make sense as TUIs too, but I don't like they way they were implemented. They mess with basic terminal features like copy/paste or scroll when there's no reason to. And they're somehow heavier than actual GUIs.

Re: Stop Making TUIs

#568
post #558

Earlier quoted context omitted.

What you describe sounds a lot like the HTML/CSS split, with having a separate semantic/display data. I think that's a rather large jump from the 80x25 model, retrofitting that much data sounds like quite the challange. Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?

New protocol entirely. The existing stuff is too baked as having positioning, movement, cells as the unit of abstraction. You need to have that available, but not as the core abstraction level. The core has to be areas, words, layout, etc. Not: "move to 20, 35, start red, bold, print border characters"

Cool, thanks for answering! I don't really want to take any more of your time, is there some place I can read up on this new proposed protocol?

Re: Stop Making TUIs

#569
post #208

Earlier quoted context omitted.

No, but I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted". I don’t want to read docs to find all keystrokes the TUI supports to achieve what I want.

You can handle mouse events in a TUI https://ratatui.rs/concepts/backends/mouse-capture/

Yeah, already in 1990, what an achievement. /s

https://en.wikipedia.org/wiki/Turbo_Vision

Re: Stop Making TUIs

#570

Earlier 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?

It’s trivially easy to run a TUI in a container. Not so much with GUIs. And, since I run as much as possible in containers, and as little as possible on my host machine, I much prefer TUIs.

It is as easy as any X Windows or RDP connection.
Post reply on HN