Live data from Hacker News

VTM: A Text-Based Desktop Environment

web.archive.org

141–145 of 145 posts

Re: VTM: A Text-Based Desktop Environment

#141
post #27
post #8

Earlier quoted context omitted.

Drawing text is the most expensive in a GUI.

That's only true for TrueType Fonts in graphical mode. In text-mode, characters are "drawn" by simply writing their ASCII code point into VRAM and writing another byte (two 4-bit values really) in an additional "attribute" buffer to set the foreground and background colour. Programmers can swap out the default character set to provide their own typeface and graphical characters for use as window borders, shadows, etc…

This sort of thing hasn't been done with the display adapter in a text mode for a decade or so, now, even on PC-compatible hardware. Even terminal emulators of this sort on Linux and the BSDs use the display adapter in graphics mode, drawing glyphs from loadable (bitmap) fonts. The sorts of systems that mysterydip was talking about might not even have hardware that provides an old-style MDA/CGA/EGA/VGA text mode, moreover.

This in addition to the fact that, as others have pointed out, the old-style text mode really doesn't lend itself well to Unicode, to the new (sic!) terminal colour systems of the 1990s, nor to proper boldface+underline+italics. (The latter is one of the reasons that commercial DOS programs from 1-2-3 to Quattro Pro were switching display adapters into graphics mode and rendering their TUIs by drawing graphics, with BGI in the case of Borland, back in the late 1980s and turn of the 1990s.)

With post-VGA blitting capabilities one can of course do things like pre-load glyph bitmaps into off-screen video RAM and blit them into the display, potentially a lot faster than having the main processor write the glyphs directly; but it is still not as simple as writing 16-bit character+attribute pairs, to do what modern users generally regard as the basics of TUIs in these modern Unicode, 24-bit colour, full ECMA-48 attribute support times.

Re: VTM: A Text-Based Desktop Environment

#142
post #124

Earlier quoted context omitted.

Same on urxvt. Probably requires true color support. I had the same issue with browsh, a text front-end to Firefox.

Oh, if only there were a way to solve this problem which was well-tested and widely-deployed! https://invisible-island.net/ncurses/

That gained 24-bit RGB colour support in version 6.1, released in 2018. It's not quite as widely deployed as you may have thought.

* https://stackoverflow.com/a/36163656/340790

Re: VTM: A Text-Based Desktop Environment

#144

Related: The MGR Window System https://hack.org/mc/mgr/ “MGR provides each client window with: curses-like terminal control functions, graphics primitives such as line and circle drawing; facilities for manipulating bitmaps, fonts, icons, and pop-up menus; commands to reshape and position windows; and a message passing facility enabling client programs to rendezvous and exchange messages.” Essentially, each window wa…

I wonder how hard it would be to write an MGR terminal emulator today.

I suspect a lot easier with modern graphics libraries and so on

Not sure I'd bother with MGR itself, but instead do something similar.

It's not as compelling now that we don't do much over serial links anymore.

The modern day version of this really is the browser/HTML.

I remember being intrigued at the time by the idea of using this protocol over a MUD (telnet / TCP socket carrying text) connection.

Post reply on HN