61–70 of 127 posts
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/
> 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)
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.
Earlier quoted context omitted.
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.
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.
Yes, I do agree the browser is the new X Windows / RDP client, on the modern timesharing systems.
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…
> 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/
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…
If you think that react (and FRP in general) is not a good way to build UIs, what is, in your opinion?
> 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)
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. The…
Did this change with 3dfx's Glide (or subsequently Direct3D once Windows got a foothold into the gaming industry)?
Earlier quoted context omitted.
> 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.
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
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.
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.