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

91–100 of 127 posts

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

#91

Post by ori_b »

Joker_vD wrote: post #80
rockorager wrote: post #40

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

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 prom…

At this point, why not just write a graphical program?

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

#92

Post by bitvoid »

justinclift wrote: post #88
mrweasel wrote: post #36

Earlier quoted context omitted.

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…

> 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 m…

Also, charm's bubbletea framework if you use golang.

https://github.com/charmbracelet/bubbletea

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

#93

Post by Joker_vD »

ori_b wrote: post #91
Joker_vD wrote: post #80

Earlier quoted context omitted.

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 prom…

At this point, why not just write a graphical program?

Unfortunately, servers are usually configured without X forwarding enabled. And the functionality I am describing already exists for terminal-based programs, it's been reimplemented multiple times — see e.g. [0][1], it's just implemented with horrible hackery (by manually driving terminal, processing raw input and counting how much lines of text the terminal screen is probably displaying right now).

I just want to, e.g. write a simple Python program that has

    for line in streaming_response.lines():
        print(line)
in one thread, and

    while True:
        cmd = input('> ').strip()
        if cmd == 'q':
             break
        if cmd == 'stop':
             requests.post(...)
        ...
in another, and be able to input my commands without the echo of my input being teared up by the output. Erlang's shell can do that. Readline can be used to do that, but Python's bindings don't export the needed functions. Swapping out the sys.stdout/sys.stdin with my custom interceptors to do this manually... barely works, slow, ugly as hell and complicated.

[0] https://github.com/thejoshwolfe/consoline

[1] https://github.com/erlang/otp/blob/90a48ae2bff26d5df67ceaa7e...

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

#96

Post by [deleted] »

thechao wrote: post #14
lynx23 wrote: 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 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…

[deleted]

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

#97

Post by zokier »

squigz wrote: post #94
mikkelam wrote: post #23

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.

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

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.

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

#98

Post by ho_schi »

actionfromafar wrote: post #48
traverseda wrote: post #4

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

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.

Post reply on HN