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

121–127 of 127 posts

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

#121

Post by joerick »

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?

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

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

#122

Post by zokier »

SoftTalker wrote: post #119
zokier wrote: post #109

Earlier quoted context omitted.

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…

> Common ssh (port) forwarding has lots of shortcomings What are the shortcomings? It always works very well when I use it.

Biggest problem is that manually adding/removing forwards in a session is a hassle. There is no standard way to communicate (to user or to ssh client) that application wants something forwarded. Finally tcp sockets do not have any sort of access control, which is problem especially on server-side.

Smaller problem is that because the applications all appear as localhost you lose some of the compartmentalization that browsers have, so different applications might end up seeing each others cookies/localstorage/cache/etc.

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

#123

Post by IWeldMelons »

anothername12 wrote: post #30
dualogy wrote: post #25

Earlier quoted context omitted.

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

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

No not VGA, CGA actually

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

#124

Post by IWeldMelons »

vetinari wrote: post #57
dualogy wrote: post #25

Earlier quoted context omitted.

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.

I think it is also 0xb800 as it is a physical address; not ionly in real mode.

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

#125

Post by arminiusreturns »

justinclift wrote: post #87
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…

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.

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)

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

#126

Post by vetinari »

IWeldMelons wrote: post #124
vetinari wrote: post #57

Earlier quoted context omitted.

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.

I think it is also 0xb800 as it is a physical address; not ionly in real mode.

For physical linear address, it would be one digit (4-bits) longer (-> 0xb8000); when the segment:offset is combined, the result is 20-bit address.

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

#127

Post by IWeldMelons »

vetinari wrote: post #126
IWeldMelons wrote: post #124

Earlier quoted context omitted.

I think it is also 0xb800 as it is a physical address; not ionly in real mode.

For physical linear address, it would be one digit (4-bits) longer (-> 0xb8000); when the segment:offset is combined, the result is 20-bit address.

Was not my point though.
Post reply on HN