Live data from Hacker News

Things I've learned building a modern TUI Framework (2022)

textualize.io

51–60 of 127 posts

Re: Things I've learned building a modern TUI Framework (2022)

#51
post #24

As a screen reader user, reading this post makes me want to scream. If you care about accessibility even one bit, for the love of god, please, don't use any of the features this post mentions. Things like animation or unicode diagrams break screen readers in horrible ways.

I would love to improve support accessibility for TUIs. Textual internally keeps a browser like DOM structure, which means it could in theory offer browser-like support for screen readers while keeping all the features offered to sighted user. But it would require a protocol to allow the app to send structured information so that the screen reader has more to work with than a matrix of characters. AFAIK this doesn't…

> AFAIK this doesn't exist

I have complained about this not existing many times and at length, and have actually been thinking about how such a think could work.

It's a great idea, but we'd need support both from screen readers, TUI libraries and some terminal emulators, and I don't know if we could get that to happen.

Re: Things I've learned building a modern TUI Framework (2022)

#52

My big complaint with textual is that it wants to be react. I can see why it would want to be react, that's a very popular framework that a lot of people are already familiar with, but I don't think it's actually a good way of doing user interfaces. But the basic reactive design is a well trod road, and basing your system design on something that's known to work is a great way to derisk the project. Sure, we'll draw…

I don't see how it is trying to be React; It definitely tries to use concepts from HTML and CSS (and perhaps even some JS?), but I actually found that it allowed me to move very quickly as I didn't need to learn a whole new UI system from scratch. I didn't need to create any component of my own, and CSS is something I already know. If anything, like I wrote in another comment, the slight layout differences and deviation from CSS is what sometimes got me a little confused.

Re: Things I've learned building a modern TUI Framework (2022)

#53

This TUI looks pretty, but I cannot imagine situation, when I would actually use it and be ready to pay for it. Probably I am not living in a right environment for it. But in my experience, either people are happy with something truly minimalistic or they try to please a user with GUI right away. For example, YouTube link in the article showed a possibility to display table with highlighting cells. Why would I need t…

The use case is something like medical billing entry where people are trained to know all of the billing codes and they still use an AS400 green screen console.

The employees work by keyboard shortcuts and are extremely efficient, and every time someone tries to replace the AS400 with a modern web app, their productivity drops 100x.

It’s the same scenario as a vim/emacs wizard vs a slick looking GUI that doesn’t have keyboard shortcuts.

Re: Things I've learned building a modern TUI Framework (2022)

#54
post #49

Earlier quoted context omitted.

The state of the art here is to detect mode 2027, and enable it when supported. This lets you know the terminal will handle graphemes properly. I maintain two TUI libraries which use this technique and emoji support has been (nearly) great. (One of which uses your uniseg library!) https://mitchellh.com/writing/grapheme-clusters-in-terminals

really great read, thanks. Im a little disappointed that no terminal emulator both implements the Kitty image protocol, and mode 2027. I wish there would be a terminal project that would just pick the best standards we have at the moment. Im not a fan of sixel for a lot of reasons. Im looking forward to trying Ghostty, though.

Ghostty has both mode 2027 and kitty image protocol

Re: Things I've learned building a modern TUI Framework (2022)

#55

Why do software engineers care so much about TUI? I really don't get it. I love a good command line program. But TUI just doesn't appeal to me.

It's the other ubiquitously installed cross-platform GUI toolkit other than the web.

Additionally, it has a hacker aesthetic. The styling is aggressively not separated from the content, and the styling knobs are pretty limited, so tui apps kind of converge on a single style. That style reminds us of hacker movies and cool sci-fi shit :)

It's not loved by corporate designers. Companies don't make sales based on their TUIs (to either businesses or consumers). So without those commercial pressures, tuis are designed by developers for developers.

Because of this, the meme of tuis self-reinforces. Developers see and use TUIs, notice that they are usually tools built with developers in mind, and then want to go on to make their own TUIs.

Re: Things I've learned building a modern TUI Framework (2022)

#57
post #25
post #12

Anyone old and naiv enough to share this observation: Almost everything I looked at after TurboVision was inspired, but actually not really finished. Once you take the toolkit for a ride, you realize its kind of cute but unfinished. Maybe another way of looking at this is to call many of the TUI frameworks I say "opinionated", whatever that exactly means. I am likely just dense and uncreative, but the truth is, when…

I get what Turbo Vision is (was), but what's that B800 thing? Surely you aren't talking about a Celeron processor? Seems tricky to google, also no Wiki page on that. You got me curious, plz spill it! =)

In real mode addressing and graphic card in text mode, your video memory started at absolute address 0xb800:0x0000. It was an two-dimensional array, where you could poke and whatever you changed here, was reflected immediately on the display. Each element of the array was two bytes: character itself and color attributes.

Re: Things I've learned building a modern TUI Framework (2022)

#58

My big complaint with textual is that it wants to be react. I can see why it would want to be react, that's a very popular framework that a lot of people are already familiar with, but I don't think it's actually a good way of doing user interfaces. But the basic reactive design is a well trod road, and basing your system design on something that's known to work is a great way to derisk the project. Sure, we'll draw…

If you think that react (and FRP in general) is not a good way to build UIs, what is, in your opinion?

Re: Things I've learned building a modern TUI Framework (2022)

#59
post #27

Why do software engineers care so much about TUI? I really don't get it. I love a good command line program. But TUI just doesn't appeal to me.

I guess, mainly because of nostalgia, back from the days TUIs were the only way to interact with computers. Turbo Vision, curses and dialog were cool back in the 1990's. Having started with computers in 1986, I really don't get the TUI fetisch, not even remote access is an issue, given X Windows, VNC, RDP, Citrix,... exist for decades.

Having run X programs over network connections quite a bit, I'd say that they make sense for graphics stuff, and textual interfaces over SSH are significantly more responsive.

But once a fixed-width text grid stops being the right tool for the job, it's likely better to have a web UI.

Re: Things I've learned building a modern TUI Framework (2022)

#60
post #25
post #12

Anyone old and naiv enough to share this observation: Almost everything I looked at after TurboVision was inspired, but actually not really finished. Once you take the toolkit for a ride, you realize its kind of cute but unfinished. Maybe another way of looking at this is to call many of the TUI frameworks I say "opinionated", whatever that exactly means. I am likely just dense and uncreative, but the truth is, when…

I get what Turbo Vision is (was), but what's that B800 thing? Surely you aren't talking about a Celeron processor? Seems tricky to google, also no Wiki page on that. You got me curious, plz spill it! =)

0xb800 is the address of the framebuffer for text. Simply write characters to that address, using offset `((row * width) + col)` and they'll appear on screen.

In graphics mode it was, IIRC, 0xa000. I once wrote a pacman-type easter egg inside the point-of-sale system[1], because doing direct graphics straight to an address is so easy and simple.

[1] Was removed after pilot and before actual release.

Post reply on HN