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

https://www.textualize.io/blog/7-things-ive-learned-building-a-modern-tui-framework/

by willm • 2 years ago

331 120 2 years ago

textualize.io

emrah2• 2 years ago

In case you missed this: Casey vs Windows terminal https://news.ycombinator.com/item?id=27725559

emrah2• 2 years ago

The first trick is "overwrite, don't clear"

This is how games were written back in the day before DirectX was a thing. You'd write directly to the frame buffer and instead of clearing and redrawing, you'd redraw what changed and what was around and under it (because there was no time to refresh the entire view in time in addition to everything else you need to do)

Neywiny• 2 years ago

I learned this from ComputerCraft programming. It's become applicable many times since then, occasionally professionally. But, the ability to tell the terminal when it's starting/done a frame is a lot more powerful IMO.

moring• 2 years ago

There were at least two other techniques back then.

The first is to write to another buffer (possibly in normal RAM, not video RAM), then when the frame is done copy the whole buffer at once, so every pixel gets changed only once.

The second is to write to another buffer that must be in video RAM too, then change the registers of the graphics hardware to use that buffer to generate pixels for the monitor to show.

They had different tradeoffs. Copying the whole buffer when done was expensive, changing an address register was cheap. But the details of the register were possibly hardware-dependent, and there was no real graphics driver framework in place. Also, to just "flip buffers" (as changing the address register was called), rendering to the off-screen buffer meant sending pixels to video RAM, which was (IIRC) slower to access than normal RAM (basically a NUMA architecture), so depending on how often a pixel gets overdrawn, rendering in normal RAM could be faster overall even with the final copy taken into account.

CBarkleyU• 2 years ago

But the details of the register were possibly hardware-dependent, and there was no real graphics driver framework in place

Did this change with 3dfx's Glide (or subsequently Direct3D once Windows got a foothold into the gaming industry)?

traverseda3• 2 years ago

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 some heavy inspiration from react.

Alright, so we're using some bastardization of CSS as well? That might be going a little bit too far. The react model already breaks the idea of CSS in a lot of ways, preferring standardized components. Sure, developers still use CSS to customize components, but I view that more as a side effect of how react evolved rather than as a justifiable architectural choice. But as long as you don't have to use CSS I suppose it's fine.

Last I tried it, you do have to use CSS. There are no good standard components, so you will be making your own, and instead of having components be one nice self encapsulated Python class the standard docs use things like list components and then style them with an external style sheet.

For those reasons textual just isn't for me yet. In python there should be one, and preferably only one, obvious way to do something. By mirroring react so closely they're also mirroring what I see as the JavaScript communities biggest vice.

itronitron3• 2 years ago

Can you elaborate on how textual wants to be like the react framework? I don't see React (or react) mentioned anywhere in the article.

traverseda3• 2 years ago

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.

willm6• 2 years ago

Last I tried it, you do have to use CSS.

You don't have to use CSS (actually you never did). Every style can be set in code, and the docs have CSS + Python equivalent for every style.

There are no good standard components

I guess its been a while since you checked https://textual.textualize.io/widget_gallery/

traverseda3• 2 years ago

Yeah, it does seem like things have changed a lot since I last used it, which I think was probably a few years ago. Time flies.

actionfromafar• 2 years ago

I want a way to embed a terminal (it doesn't have to support a myriad terminal emulations, only one) inside a graphical program. MacOS first, but other platforms would be nice.

So, imagine a normal GUI window, but one of the components in it is a terminal window. Is there something like that?

Or should I just use mono font text view?

ho_schi• 2 years ago

GNOMEs Gtk has a companion library named libvte which provides the terminal as widget. It is used by Gnome-Terminal (and many other terminals) itself and now supports Gtk4:

https://gitlab.gnome.org/GNOME/vte

Basically its usage starts with vte_terminal_new().

Unicode? Emojis? https://gitlab.gnome.org/GNOME/vte/-/blob/master/doc/ambiguo...

What hurts me? The only thing which hurts me is that the maintainer doesn’t like background transparency in the official terminal application. The library supports it and many terminals use it. But this is another topic. With an embedded terminal you will likely not use that feature ;)

PS: KDE likely has a smiliar solution within Qt. As you named portability either Gtk or Qt are you tools. The biggest hurdle is shipping the libraries on macOS. On Linux it is done automatically. Windows is rather easy. Regarding Gtk, ship the gdk-pixbuf loaders alongside, they are loaded at runtime via dlopen(). The small differences hurt during porting.

aatd86• 2 years ago

People probably simply emulate a terminal window and execute the commands via the OS APIs (syscalls). This is unlikely to be truly "embedding".

joerick• 2 years ago

I've used xterm.js for this, but I was already in a webview. It's pretty good, might even be worth the webview for https://github.com/xtermjs/xterm.js Used by vscode among others

yoavm2• 2 years ago

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.

nine_k3• 2 years ago

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

sesm2• 2 years ago

I don't agree that React is FRP. FRP is a generic solution that builds data-UI synchronization around data, and assumes that incremental UI updates will be written in UI code. React puts data-UI synchronization code inside UI components and provides an Immediate Mode-like API to avoid writing incremental updates in UI code.

spencerchubb• 2 years ago

Interesting that they're hiring. I'm curious how they plan to make money from a TUI framework

itronitron3• 2 years ago

the jobs link gives a 404 error

__float• 2 years ago

This post 2 years old, it seems they have filled their open roles :)

ynniv2• 2 years ago

He mentioned eventually running on the web, so my guess is to facilitate migrating old TUIs. There's plenty of consulting money in maintaining old enterprise software.

tyre2• 2 years ago

Yeah same question. It looks like they’re building some pretty cool software, but engineers are expensive and other frameworks exist.

davepdotorg• 2 years ago

Those positions were filled and then subsequently removed: https://blog.davep.org/2024/03/28/goodbye-textualize.html#go...

rivo• 2 years ago

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 own unique solutions to the problem because character width is not standardized and terminals are messy, as noted in the article. OP simply supports Unicode 9 only (Unicode is at version 15.1 at the moment). Sooner or later, users will complain, however, that certain emojis or international characters are not rendered correctly. So I'm not sure that this is a great solution.

roland35• 2 years ago

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

kevindamm• 2 years ago

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

Joker_vD3• 2 years ago

It doesn't matter; what matters is that both your (terminal-manipulating) program and terminal emulator agree on the symbols widths. Considering that they usually won't (lots of terminal emulators have their own hand-crafted, statically linked wcwidth/wcswidth functions; the readline library also has them hard-coded, by the way), it's quite frustrating.

rockorager2• 2 years ago

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

sweeter• 2 years ago

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.

Joker_vD3• 2 years ago

I personally don't think this mode is all that very useful, to be fair. First of all, the grapheme clustering is not set in stone, it's been changed from one Unicode standard version to other.

Second, and this is mostly because my personal use cases are very humble, a much, much simple to implement workaround, for everyone involved, would be a couple of OSC sequences which would mark a part of output text as the prompt (when terminal is in canonical/cooked mode), so that a huge chunk of readline could be simply thrown away.

So your program could just print a prompt, and then simply read the cooked line. In the meanwhile, the terminal emulator would handle line editing, line-wrapping and asynchronous output: if you keep outputing text to the terminal while a prompt is active, the terminal would clear the prompt and the unfinished line, print the text, then re-display the prompt and the line; basically what all "async readline" libraries do already with rl_clear/rl_redisplay — but doing it in the terminal would take care of this properly, because the terminal definitely knows how wide all the symbols it itself thinks are. And the tab completion could be supported by returning a <TAB>-terminated line to the program, instead of an <LF>-terminated line.

Unfortunately, I don't think something like this can actually become even moderately widely adopted.

Edit: Or, you know, maybe we could extend terminfo? Like, introduce twcswidth() function that would take your string, and the somehow encoded Unicode grapheme clustering data that the current terminal is actually using which you can query from terminfo, and return the number of screen cells it would take on this terminal.

kevin_thibedeau• 2 years ago

That isn't sufficient. Codepoints with ambiguous width can't be detected in a standard way. A large number of pre-emoji symbols have been upgraded to have emoji presentation. Some systems default them to emojis with wide rendering, others maintain the text presentation with narrow rendering. Many systems ignore the presentation selectors if you want to force it.

lynx23• 2 years ago

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 switched from DOS to Linux in the 90s, I was never again as productive as I happened to be with B800. Granted, it likely took me a long time to understand the need for double buffering and the difference between a local/direct text mode vs a terminal, let alone escape sequences. But still. Whenever I tried to do something directly in ncurses, I pretty much gave up due to a distinct feeling of being unhappy. Completely different to what I was able to do with the simple ideal of B800.

thechao• 2 years ago

I learned GUI programming using win16, then win32 — this would've been during the transition to WinXP. I must have a city-wide blind spot, but every post message pump GUI framework has left me completely befuddled. One thing I never understood was how these OO frameworks helped to really solve the multithreaded UI issues. In Win32, I just threw the main renderer into a thread, then had support renderers build models "on the side", and then updated the difference. The code never really got out of hand.

dualogy• 2 years ago

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! =)

anothername12• 2 years ago

Ok I think he’s referring to 0xB800, the VGA text buffer segment in real mode.

vetinari2• 2 years ago

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.

lelanthran• 2 years ago

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.

ynniv2• 2 years ago

If you're going to run kitty it can do a lot more than that: https://m.youtube.com/watch?v=ft1Q-DwGWIs

https://notcurses.com/

nine_k3• 2 years ago

I prefer WezTerm over Kitty, because of the Kitty's author attitude towards feature requests and even pull requests. And yes, you can do graphics on both, using the same protocols. If you really need graphics, a terminal is hardly a right solution. It's occasionally useful for tiny stuff like icons though.

ranger_danger• 2 years ago

Do you also prefer Windows because of Linus' attitude?

cocodill• 2 years ago

Humanity needs more TUI tools

miki1232113• 2 years ago

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.

willm6• 2 years ago

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

The most promising way forward for accessibility is the web support for Textual. It would be possible for the app to work with the browser to make highly accessible TUIs.

blooalien• 2 years ago

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.

miki1232113• 2 years ago

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.

kbouck• 2 years ago

This TUI discussion triggered a bit of 80s/90s programming nostalgia -- anyone remember TTT (TechnoJock's Turbo Toolkit)? Pre-gui era UI framework.

RunSet• 2 years ago

I use monodraw for these diagrams. Monodraw is MacOS only unfortunately, but there are no doubt good alternatives for other platforms.

https://github.com/Nokse22/ascii-draw

mikkelam• 2 years ago

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.

willm6• 2 years ago

Each to their own. But running apps over SSH is a big plus. And some folk, like myself, enjoy the snappy keyboards focused experience that perhaps GUI apps could offer, but typically don't.

pjmlp2• 2 years ago

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.

nine_k3• 2 years ago

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.

consteval• 2 years ago

X Windows, VNC, RDP, Citrix,... exist for decades.

Yeah but those are all awful. I mean, okay, they work almost okay with a wired network connection and on the same network.

But as soon as you hit the WAN and you throw wifi in there it's painful. Having noticeable latency and graphical artifacts does, in my opinion, hurt productivity. For those pieces of software where completing tasks as fast and accurately as possible is the most important goal, TUIs are great. Especially when you have comprehensive keyboard shortcuts. If you've ever seen an office worker rip through a TUI underwriting a loan, you'll know what I mean.

fastasucan• 2 years ago

Its great for running things in a terminal where you want more of a user interface than a CLI. Sometimes a TUI is faster and gives better oversight than a CLI.

habitue• 2 years ago

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.

electroly• 2 years ago

There isn't much obvious benefit in using TUIs, but writing TUIs has a big upside: it's easier in most ways. It's trivially cross-platform, you don't have to make pixel-perfect GUIs (because it's impossible), you don't need icons or graphics (because you can't show graphics), etc.

ofseed• 2 years ago

That's the main reason. TUI programs can be created quickly, and they're mostly developer-oriented, so they just need to be useful enough and don't need to be optimized as much as a GUI program.

sam1r4• 2 years ago

Because you may have no issue using browsers with extended batteries + features.

How about displaying data on cli w/ textualize vs on an admin web interface.

I find it much easier + direct to use some py-orm w/ textualize.

On an admin interface you’d have to worry about auth + some js ui framework that prints your custom html directives to tables… that eventually display text.

squigz2• 2 years ago

Because I don't need a resource-heavy GUI for something as simple as a music player.

zokier4• 2 years ago

GUI is not intrinsically any more resource-heavy than TUI; ultimately you need to render stuff on screen somehow and get user input, and going through tty layer just is extra bloat.

wpm• 2 years ago

I like TUIs because they are usually the exact opposite of the large range of UX fashions that absolutely suck, and have infected every other GUI app and website I use. The terminal is a breath of fresh “I’m not going to treat you like a moron” “more is more” “you’ll know if it’s a button” high contrast air.

citrin_ru• 2 years ago

I use CLI heavily but some tasks GUI suits better and TUI is a middle ground between GUI and CLI - you can continue using your terminal emulator with you favorite font but have a GUI like interface. Also all TUI applications I've used have low response time. Most GUI apps are also has fast interface (most of the time) but all frustratingly slow apps I've used were GUI apps.

bogdan-lab• 2 years ago

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 that as TUI? Probably if I want to navigate through table with highlighting active cell I would also need a bunch of other stuff and eventually I would need a proper GUI.

seeknotfind• 2 years ago

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

sam1r4• 2 years ago

Or what if you just prefer to not use a browser to get your information on the internet. Textualize is like the only choice I can jump to.

It’s much better to hyperlink and open image and video in the browser from the terminal. In my opinion. Playing it would just block your terminal session, so it’s pretty annoying to have to open another tab with an inline video playing. I am happy with the features with textualize and haven’t even thought about needing things that play over a duration beyond a few seconds.

Textualize then becomes the browser api that I build my terminal browser and render only the components I care about.

None of that background or js libraries, ads. It’s well worth it.

mrweasel• 2 years ago

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.

justinclift2• 2 years ago

Personally I found Textual a little weird to use, but better than ncurses.

Out of curiosity, have you looked at it's sibling project "rich"?

https://github.com/Textualize/rich

Seems like it provides a TUI toolkit as well, and it looks a bit less weird than the approach Textual uses.

Was thinking of trying it out with a side project recently, but got pulled onto some other stuff instead so haven't yet started. Nor made the choice between them. ;)

halfcat• 2 years ago

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.

tyre2• 2 years ago

The solution to manual medical billing is to have computers do the billing. The system can be configured via GUI with rules about billing codes, payers, DX codes, etc. and then the rest of the system Just Does It.

(I work at a company automating medical billing.)

justinclift2• 2 years ago

Proper GUI's are nice and all, until you need to do the same thing over an ssh connection.

Sometimes that works ok (ie forwarding X on a high bandwidth connection), but other times the proper GUI acts like a complete pig. :(

A text based GUI sounds like it might be the best of both worlds.

arminiusreturns• 2 years ago

greybeard nix admin here: I agree People have forgotten way too many of the lessons we learned in Ops Companies like to slap "agile" and "devops" labels on things, but I see the same old fights... (biased because I hate gui-ninjas)

hggh• 2 years ago

(2022)

yoavm2• 2 years ago

I've used Textual to build a quick Swedish-English dictionary that runs in terminal but also works using touch, when using the laptop as a tablet and on my Android phone. It was a pretty smooth experience and was very fast to get something working. The TCSS layout system thing is a little strange, but only because I automatically expected it to be CSS and obviously that doesn't really work in the terminal.

https://yoavmoshe.com/blog/learning-swedish-with-sway-and-an...

troupo• 2 years ago

On emojis I highly recommend "Emoji under the hood" https://tonsky.me/blog/emoji/

lofenfew• 2 years ago

There is a heuristic where you write various sequences and ask the terminal for the cursor position, which should make an educated guess as the Unicode version. Unfortunately from testing we've discovered that terminals still render emoji unpredictably even if you think you know the Unicode database used.

Rather than using this as a heuristic, couldn't you simply use this whenever you need to determine the width of a string? Write it to the terminal, if it ends up going farther than you expected, then you need to wrap it somewhere. I used a trick like this at one point after I got annoyed with wcwidth.

rtpg• 2 years ago

RE Fractions, for _many people_, decimal.Decimal will work very well.

For layout concerns, fractions are probably a more natural fit (things like 1/3), but Decimal is a great floating point default for a lot of problems. They aren't exact, but a lot of the "normal" floating point weirdness goes away and your results look a lot more human. Highly recommend if you don't have a perf reason not to.

DrMiaow• 2 years ago

Nice! I had no idea about "Synchronized output" mode.

I'm adding that to my CLI project. https://youtu.be/NxsaHxON350?si=319RyQPsb5AVDQj9

sam1r4• 2 years ago

Whoa! That is so cool. Thanks for the use case example.

frontporch• 2 years ago

terminals are fast

their slow as hell and incredibly inefficient to build graphics on top of

but many are powered by the same graphics technologies used in video games

what does that mean? obviously they have to render text to graphics at some point

The first trick is "overwrite, don't clear". If you clear the "screen" and then add new content, you risk seeing a blank or partially blank frame for a brief moment.
The second trick would be to write new content in a single write to standard output.

its just luck when any of these work

The third trick would be to use the Synchronized Output protocol;

this could work...

With these three tricks in place you can create very smooth animation as long as you can deliver updates at regular intervals. Textual uses 60fps as a baseline. Any more than that probably isnt going to be noticeable.

no, anything above 60hz will be noticeable more smooth and less laggy. also this isnt a question about bigger=better. youll notice jank even if you run 75fps on 60hz or 60fps on 75hz, and of course with unsynchronized rendering there will be jank and other artifacts even with Xfps on Xhz.

Now that you can have smooth animation in the terminal, the question becomes should you?

nothing you demonstrated was smooth, just better than current broken (terminal) shit. and no, because the thing terminals miss out on is being able to scroll at just a constant pixel/time rate and actually follow the mouse precisely and without lag. as you can see in the video you cant do this because the terminal cant do this period because they can only move one font width/height per step. then if we actually explore this issue well soon find out a 125hz mouse polling rate adds tons of jank, and well discover 60hz is too slow to be smooth even with perfect sync, then that you need a CRT to have legible text at such a slow framerate. your video looks like a slightly faster windows 3.0. which is good for a terminal, but bad compared to what graphics could do even 20 years ago (at 60hz), no your not scrolling at 60hz, because thats impossible in the terminal.

none of this means i want what Windows / GTK / KDE / android / ... came up with where you press a button and the program then starts slowly animating something like its (ironically) a type writer instead of just doing what i said. you lose your position in scrolling because its done wrong, the "smooth scrolling" shit in firefox or whatever is just a poor (oblivious) attempt at the solution

efilife• 2 years ago

They are slow!

sam1r4• 2 years ago

Thank you so much for making this. I use this quite regularly + rigorously for my own personal tracking, scheduling and much more.

Thanks to textualize, I can interact with the external world with full control in a black box.

tuieachtheirown• 2 years ago

FWIW, I evaluated a dozen compiled TUI libraries and found FTXUI to be the easiest to use and most reliable:

https://github.com/ArthurSonzogni/FTXUI

It's a nice tool to build interactive dashboards with both keyboard and mouse support.

theanonymousone• 2 years ago

Isn't it written in 2022, hence requiring the year in the title?

snthpy• 2 years ago

I think this should include (2022) in the title.

zokier4• 2 years ago

Many people here mention SSH as one motivating uses for TUIs. It's a shame that we don't have standardized HTTP forwarding over SSH that would work as seamlessly as X forwarding can work.

f1refly• 2 years ago

We have -L though, isn't that kind of what you're looking for?

zokier4• 2 years ago

Common ssh (port) forwarding has lots of shortcomings that make it far less practical than X forwarding for this sort of use.

Sketching out this idea, what I'd want is that ssh would set some standardized env var pointing to unix socket (analogous to $DISPLAY), and applications when starting up should pick that up. That should trigger applications to start listening on another unix socket (instead of tcp port), and notify ssh through the socket pointed by the env var. Upon that notification, ssh should set up new tunnel and open new browser window pointing to the tunnel.

Nothing about that is technically particularly difficult (I'd say its almost trivial), but it'd need standardization to be truly useful.

superlopuh• 2 years ago

We use Textual as an interactive way to explore compilation pipelines in xDSL [0]. As our compiler is written in Python, it was the perfect tool to build a UI in the same language as the existing codebase. After starting the `xdsl-gui` project, we found Marimo [1], a reactive notebook for Python, which also lets users build apps in Python. It's been interesting to compare these two, especially in the way they handle state and propagate updates. For now we're using both tools, but it might make sense to centralise at some point. Both of these frameworks like immutable data structures, which I find is a positive incentive to use immutability throughout the code, and has been good for the rest of the project.

[0] https://xdsl.dev/ [1]: https://marimo.io/

zelphirkalt• 2 years ago

Is there any terminal, that throws out all the stone age terminal stuff, like weird codes for starting colored output and stopping colored output? A terminal, that instead makes use of some XML tags or so, to mark text in a readable fashion as prompt, input, output, maybe variables and such, colored and non-colored, etc., and then simply has some logic to render that XML correctly?

Of course that would lead to not recognizing weird color codes and so on, but perhaps there could be a plugin system, where one could add a plugin that transforms color codes and such in the output into XML tree representation.

And then one could perhaps log the whole thing in various formats: Only visible text with colors, without colors, whole XML tree, or as JSON, or whatever other format it translates well to. Also could be extended via plugin.

But bare bones it merely treats everything as text.

SoftTalker2• 2 years ago

A terminal, that instead makes use of some XML tags or so, to mark text in a readable fashion as prompt, input, output, maybe variables and such, colored and non-colored, etc., and then simply has some logic to render that XML correctly?

That would be a browser. Forgive me if you were being sarcastic and I didn't pick up on it.

qwerty456127• 2 years ago

How comes we had perfect TUIs and no problems on DOS yet apparently always have some problems with TUIs on Linux?

saulpw• 2 years ago

Unicode, primarily.

gudzpoz• 2 years ago

Emojis are terrible

Not just emojis. Recently I've had some fun trying weird Unicode characters in different terminals (e.g. 𒐫):

- QTerminal/Konsole: Tofu

- Xfce terminal: Results in overlaps with characters that comes after it.

- Alacritty: Similar to Xfce terminal, but glitches when the cursor/glyph moves.

- COSMIC term: No overlapping glyphs, except that the line then wraps only after it grows out of screen.

- Kitty/WezTerm: Scales the glyph to fit it into a single column. (Barely legible.)

I don't even known what to expect. It is indeed a mess over there.

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

Related Stories