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.
Things I've learned building a modern TUI Framework (2022)
111–120 of 127 posts
Re: Things I've learned building a modern TUI Framework (2022)
#112Earlier quoted context omitted.
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.
Okay well, maybe you should tell that to the GUI developers :P
Re: Things I've learned building a modern TUI Framework (2022)
#113If 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/
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.
Re: Things I've learned building a modern TUI Framework (2022)
#114My 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?
Re: Things I've learned building a modern TUI Framework (2022)
#115Why 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.
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.
Re: Things I've learned building a modern TUI Framework (2022)
#116Re: Things I've learned building a modern TUI Framework (2022)
#117How comes we had perfect TUIs and no problems on DOS yet apparently always have some problems with TUIs on Linux?
Re: Things I've learned building a modern TUI Framework (2022)
#118Is 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 re…
That would be a browser. Forgive me if you were being sarcastic and I didn't pick up on it.
Re: Things I've learned building a modern TUI Framework (2022)
#119Earlier quoted context omitted.
We have -L though, isn't that kind of what you're looking for?
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 n…
What are the shortcomings? It always works very well when I use it.
Re: Things I've learned building a modern TUI Framework (2022)
#120Not 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.