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

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

textualize.io

Post reply on HN
Print view View original

31–40 of 127 posts

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

#31

Post by kevindamm »

roland35 wrote: post #15
rivo wrote: post #9

It's funny how every TUI developer eventually stumbles over Unicode and then handling international characters and emojis correctly turns into its own project close to the same scope of (or even bigger than) the original TUI project. It happened to me on rivo/tview and through the resulting rivo/uniseg package, I learned that all other TUI library maintainers deal with the same issues. Finally, everyone invents their…

Are there any libraries in place which can normalize all emojis down to a single symbol?

It's a design decision. On one end, if I'm reading your question correctly, you could use 0xFFFD (the replacement character) for anything not recognized as language-specific characters in the BMP and SMPs (this can be done within practically all existing Unicode libraries by filtering on character class) which will inadvertantly filter some non-emoji symbols and doesn't really convey any information (it can even look unprofessional, it reminds me a lot of the early web during the pre-unicode growing pains of poorly implemented i18n/l11n).

There are libraries like Unidecode[0py] [0go] [0js] which convert from unicode to ASCII text that might be easiest to include in a TUI. All the ones I looked at will convert emoji to `[?]` but many other characters are converted to that, too, including unknowns.

On the other end you can keep a running list of what you mean by emoji[1] and pattern match on those characters, then substitute for a representative emoji. But it will still pose some difficulty around what to choose for the representative symbol and how to make it fit nicely within a TUI. An example of a library for pattern-matching on emoji is emoji-test-regex-pattern[2] but you can see it is based on a txt file that needs to be updated to correspond with additions to Unicode.

[0py]: https://github.com/avian2/unidecode

[0go]: (actually there are a few of these) https://pkg.go.dev/github.com/gosimple/unidecode

[0js]: https://github.com/xen0n/jsunidecode

[1]: these aren't really contiguous ranges, and opinions vary, see https://en.m.wikipedia.org/wiki/Emoji#Unicode_blocks

[2]: https://github.com/mathiasbynens/emoji-test-regex-pattern

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

#33

Post by seeknotfind »

bogdan-lab wrote: post #29

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…

One reason to prefer textual UIs is that you can use them from any computer anywhere fast (no slow video VNC). Also, if you are already using a terminal, then improving that experience is nice. There is a big enough market there for this company.

However, I'm not sure what a "proper" GUI is. Terminals have a widely used open standard. These protocols are more standard and interoperable than any GUI framework, and they are supported on every system. Once you add video in there, close a few more gaps, I think competing with the browser, or bringing the full computer experience to the terminal is reasonable.

Obviously if terminals add something like video, it's "copying" rendering pipelines from "proper" GUIs, but making the terminal experience better, which could also be viewed as bringing UNIX zen to GUIs, if it makes it big, you'll love it too! <3

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

#34

Post by kragen »

willm wrote: post #16
traverseda wrote: post #10

Earlier quoted context omitted.

They have a virtual DoM https://textual.textualize.io/api/dom_node/ This includes a lot of what you'd expect from HTML, classes, CSS, etc. They have reactive attributes https://textual.textualize.io/guide/reactivity/ It has HTML (or at least a DoM), css, and you design widgets the same way.

> They have a virtual DoM https://textual.textualize.io/api/dom_node/ It's not a virtual DOM. It's not technically even a DOM, because there is no Document. The name has stuck, which is why we went with that. Technically, its a tree. One of the most common data structures used to represent a UI, and predates React by decades. > This includes a lot of what you'd expect from HTML, classes, CSS, etc. It has CSS in commo…

this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable

hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho

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

#35

Post by blooalien »

willm wrote: post #24
miki123211 wrote: post #19

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…

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

Isn't it possible to expose this content via a publicly accessible API that screen readers could simply hook into? BTW, thank you so very much for Rich and Textual. Wonderful tools. Love 'em.

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

#36

Post by mrweasel »

bogdan-lab wrote: post #29

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…

It does seems niche at this point. One scenario I can see is where you want something more user friendly than pure CLI and where providing a web UI might be too risky for some reason. A TUI could allow users to SSH in to server somewhere and just have TUI app as their shell. It's a bit contrived I grant you that.

Personally I found Textual a little weird to use, but better than ncurses. Though it didn't really yield what I wanted. I like the old mainframe style TUI application, those already struck me as being wildly efficient.

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

#37

Post by willm »

kragen wrote: post #34
willm wrote: post #16

Earlier quoted context omitted.

> They have a virtual DoM https://textual.textualize.io/api/dom_node/ It's not a virtual DOM. It's not technically even a DOM, because there is no Document. The name has stuck, which is why we went with that. Technically, its a tree. One of the most common data structures used to represent a UI, and predates React by decades. > This includes a lot of what you'd expect from HTML, classes, CSS, etc. It has CSS in commo…

this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho

I only meant to rebut the factual claims made in the previous comment. Textual is inspired by web development (and I've always described it as such), but "want to be react" is way overblown. It has things in common with React, but equally many other web and UI frameworks. Heck you could say that Textual wants to be JQuery, and that would be just as apt...

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

#38

Post by willm »

blooalien wrote: post #35
willm wrote: post #24

Earlier quoted context omitted.

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…

> 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. Isn't it possible to expose this content via a publicly accessible API th…

De nada!

> Isn't it possible to expose this content via a publicly accessible API that screen readers could simply hook into?

Definitely possible from a technical standpoint, but I don't know of anyone who has done that. Maybe one day, Textual could provide that solution.

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

#39

Post by estebank »

kevindamm wrote: post #31
roland35 wrote: post #15

Earlier quoted context omitted.

Are there any libraries in place which can normalize all emojis down to a single symbol?

It's a design decision. On one end, if I'm reading your question correctly, you could use 0xFFFD (the replacement character) for anything not recognized as language-specific characters in the BMP and SMPs (this can be done within practically all existing Unicode libraries by filtering on character class) which will inadvertantly filter some non-emoji symbols and doesn't really convey any information (it can even look…

There's a "trick" that works somewhat well for some compound emoji like "family": replace ZWJs with whitespace. Emoji width is not standardized because it depends on platform, fonts available, shell and terminal emulator, but almost no terminal supports compound emoji correctly. Because of how they were designed, most terminals will print the emoji as its component parts. If you need to do something like underline a piece of text (like rustc has to) we decompose them ourselves, and then it is a more tractable problem to know what the width of a char is (0, 1 or 2, and var width for tabs, which we just transform to a hardcoded 4—incorrect but usable). This can still be incorrect, on specific terminals, but works well enough on most.

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

#40

Post by rockorager »

rivo wrote: post #9

It's funny how every TUI developer eventually stumbles over Unicode and then handling international characters and emojis correctly turns into its own project close to the same scope of (or even bigger than) the original TUI project. It happened to me on rivo/tview and through the resulting rivo/uniseg package, I learned that all other TUI library maintainers deal with the same issues. Finally, everyone invents their…

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

Post reply on HN