[HN Gopher] Twin - A Textmode WINdow Environment
       ___________________________________________________________________
        
       Twin - A Textmode WINdow Environment
        
       Author : kim_rutherford
       Score  : 144 points
       Date   : 2025-06-15 20:07 UTC (1 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | kristopolous wrote:
       | Reminds me of
       | 
       | https://en.m.wikipedia.org/wiki/DESQview and
       | https://en.m.wikipedia.org/wiki/IBM_TopView
       | 
       | It'd be interesting to try this concept again on the wildly
       | different computers we have now compared to 40 years ago.
       | 
       | 4k monitors, high speed networks, dozens of cores, things are
       | significantly different - might open some wildly exciting and new
       | possibilities
        
         | skissane wrote:
         | Also reminds me of https://en.wikipedia.org/wiki/AlphaWindows
         | 
         | Although I've never succeeded in locating a copy of the spec,
         | any implementations, even a screenshot... would be great if any
         | of them turned up some day
        
           | eschaton wrote:
           | This should have enough to build either an emulator or a
           | window manager.
           | 
           | https://bitsavers.org/pdf/displayIndustryAssociation/AlphaWi.
           | ..
        
             | skissane wrote:
             | Also there is a firmware dump for the HP 700/70 which
             | implemented it:
             | https://bitsavers.org/pdf/hp/terminal/700/HP_700_70_C1093/
             | 
             | Likewise for the Televideo 995-65:
             | http://bitsavers.org/pdf/televideo/995/firmware/
        
         | jd3 wrote:
         | I'm a fan of the tiles/patterns from DESQView/X
         | 
         | https://news.ycombinator.com/item?id=16044021
        
           | kristopolous wrote:
           | I got Desqview/X running about 25 years ago on some Everex.
           | An X Terminal that ran win16 software - Useless but
           | fascinating.
           | 
           | IIRC there was some additional minimal runtime stuff like
           | perl/awk/sed that came with it kinda like MinGW later on
        
             | johng wrote:
             | Same experience here. It blew my mind but it wasn't really
             | useable.
        
         | boznz wrote:
         | and Borland Turbovision
        
         | ivolimmen wrote:
         | ... and visual basic 1.0 for DOS
        
         | nickdothutton wrote:
         | Got hold of a free copy of this as a student, on underpowered
         | PCs at college and it was a superpower.
        
         | icedchai wrote:
         | I was just about to same the same thing! I remember briefly
         | running DESQview on a 386SX, before installing Linux...
        
       | matt3210 wrote:
       | Peak UI for sure!
        
       | behnamoh wrote:
       | Does it support Liquid Glass? :')
        
       | snvzz wrote:
       | Last I checked (easily been a decade) it had a major limitation
       | in not supporting Unicode.
       | 
       | I wonder if this was ever resolved.
        
         | JdeBP wrote:
         | It seems to have supported UTF-8 for at least a decade.
         | Although it went the full-on ECMA-35 route of making that an
         | optional switchable character set.
         | 
         | There was an issue back in 2016 where, ironically, it was
         | coming up in Latin-1 mode with everything else around it
         | talking UTF-8, and there have been other similar impedance mis-
         | matches over the years. But they seem to hinge on it actually
         | having UTF-8 support.
         | 
         | * https://github.com/cosmos72/twin/issues/4
         | 
         | * https://github.com/cosmos72/twin/issues/7
         | 
         | * https://github.com/cosmos72/twin/issues/8
         | 
         | However: There was no 256 colours support as of 2021.
         | 
         | * https://github.com/cosmos72/twin/issues/30
         | 
         | And in some places it even required IBM code page 437.
         | 
         | * https://github.com/cosmos72/twin/issues/22
         | 
         | And some of the doco seems to have never been incorporated.
         | 
         | * https://github.com/cosmos72/twin/issues/100
        
           | cosmos0072 wrote:
           | Author here :)
           | 
           | I've been using Twin as my everyday terminal emulator and
           | terminal multiplexer since ~2000, slowly adding features as
           | my free time - and other interests - allowed.
           | 
           | As someone pointed out, the look-and-feel reminds Borland
           | Turbo Vision. The reason is simple: I started writing in in
           | the early '90s on DOS with a Borland C compiler, and I used
           | the Borland Turbo Vision look-and-feel as a visual guideline
           | (never actually looked at the code, though).
           | 
           | The porting to linux happened in 1999 (it was basically
           | dormant before that), and Unicode support was progressively
           | added around 2015-2016 (initially UCS-2 i.e. only the lowest
           | 64k codepoints, then full UTF-32 internally, with terminal
           | emulator accepting UTF-8). There are still some missing
           | features, most notably: no grapheme clusters, no fullwidth
           | (asian etc.) support, no right-to-left support.
           | 
           | Right now I'm adding truecolor support (see
           | https://github.com/cosmos72/twin/tree/truecolor) - it's
           | basically finished, I'm ironing out some remaining bugs, and
           | thinking whether wire compatibility with older versions is
           | worth adding.
           | 
           | And yes, documentation has been stalled for a very long time.
           | 
           | Retrospectively, I should have switched C -> C++ much
           | earlier: lots of ugly preprocessor macros accumulated over
           | time, and while I rewrote the C widget hierarchy as C++
           | classes, several warts remain.
        
             | panzi wrote:
             | Do symbols for legacy computing work with it? Especially
             | the 1/8ths vertical/horizontal blocks?
        
               | cosmos0072 wrote:
               | If you mean the Unicode glyphs listed at
               | https://en.m.wikipedia.org/wiki/Block_Elements they are
               | supported - you just need a display driver that can
               | render them. For example, `twin --hw=xft` (it's the
               | default) or `twin --hw=X11`, both with a font that
               | contains them
        
               | JdeBP wrote:
               | Xe means the Unicode block that is actually named
               | "Symbols For Legacy Computing". It's not in the BMP. Some
               | bloke named Bruce was doing TUI windows with scrollbars
               | and sizer/menu boxes some years before TurboVision and
               | code page 437. (-:
        
               | panzi wrote:
               | Indeed I meant these: https://en.wikipedia.org/wiki/Symbo
               | ls_for_Legacy_Computing
               | 
               | I use them in some tiny hobby projects like these:
               | 
               | https://github.com/panzi/progress-pride-bar
               | 
               | https://github.com/panzi/bad-apple-terminal
               | 
               | https://github.com/panzi/js-unicode-bar-chart
               | 
               | https://github.com/panzi/js-unicode-plot
               | 
               | https://github.com/panzi/js-unicode-progress-bar
               | 
               | https://github.com/panzi/python-term-flags
        
               | JdeBP wrote:
               | Reading the flags one: Unscii has font coverage, if you
               | want to try that out on the emulators whose fonts were
               | problems.
               | 
               | * https://news.ycombinator.com/item?id=43812026
        
               | JdeBP wrote:
               | Given that it's drawing TUI windows, the MouseText
               | characters for doing that very thing on the Apple IIe
               | would seem even more pertinent.
               | 
               | * https://tty0.social/@JdeBP/114409020672330885
        
             | JdeBP wrote:
             | Alas, it's not finished. You've made the mistakes that all
             | of us have made, and haven't caught up with us, must of us
             | having fixed those mistakes, a few years back when
             | implementing 24-bit RGB was in vogue.
             | 
             | This is not, as the function name suggests, a colon, but
             | per ITU/IEC T.416 it should be:
             | 
             | https://github.com/cosmos72/twin/blob/truecolor/server/hw/h
             | w...
             | 
             | And not only should this have colons too, but per ITU/IEC
             | T.416 there's a colour space parameter that goes in there:
             | 
             | https://github.com/cosmos72/twin/blob/truecolor/server/hw/h
             | w...
             | 
             | The unfortunate part is that when rendering to a terminal,
             | you don't have any available mechanism apart from hand-
             | decoding the family part of the TERM environment variable,
             | and knowing who made which mistakes, to determine which of
             | the 7 possible colour mechanisms are supported. They are:
             | 
             | 1. ECMA-48 standard 8 colour, SGRs 30 to 37, 39, 40 to 47,
             | and 49
             | 
             | 2. AIXTerm 16 colour, ECMA-48 plus SGRs 90 to 97 and 100 to
             | 107
             | 
             | 3. XTerm 256 colour, ITU T.416 done wrongly with SGR 38;5;n
             | and SGR 48;5;n
             | 
             | 4. XTerm 256 colour corrected, ITU T.416 done right with
             | SGR 38:5:n and SGR 48:5:n
             | 
             | 5. 24-bit colour take 1, ITU T.416 done wrongly with SGR
             | 38;2;r;g;b and SGR 48;2;r;g;b
             | 
             | 6. 24-bit colour take 2, ITU T.416 done wrongly with SGR
             | 38:2:r:g:b and SGR 48:2:r:g:b
             | 
             | 7. 24-bit colour take 3, ITU T.416 done right with SGR
             | 38:2::r:g:b::: and SGR 48:2::r:g:b:::
             | 
             | Few people support 4, and although quite a lot of us have
             | finally got to supporting 7 it isn't quite universal.
             | Egmont Koblinger, I, and others have been spreading the
             | word where we can over the last few years.
             | 
             | This is where I was at in 2019:
             | 
             | https://github.com/jdebp/nosh/blob/trunk/source/TerminalCap
             | a...
             | 
             | There a few updates to that that are going to come out in
             | 1.41, but when it comes to colour they're mainly things
             | like recognizing the "ms-terminal" and "netbsd6" terminal
             | types in the right places.
        
               | cosmos0072 wrote:
               | Yep, I am well aware of the `;` vs `:` confusion in both
               | 256 color and 24-bit color control sequences.
               | 
               | Short of hand-coding "which terminal supports which
               | variant" I do not know any standard mechanism to detect
               | that (beyond the well-known $TERM=...-256color and
               | $COLORTERM=truecolor or $COLORTERM=24bit)
               | 
               | I guess I'll have to add command line options to choose
               | among the variants 1...7 you helpfully listed above.
               | 
               | My main use it to render twin directly on X11, which
               | avoids all these issues, and while rendering inside
               | another terminal is important and is not going away, I am
               | OK with a few minor color-related limitations (note:
               | limitations, not bugs) in such setup, especially if the
               | other terminal does not follow the relevant standards
        
               | skissane wrote:
               | > This is not, as the function name suggests, a colon,
               | but per ITU/IEC T.416 it should be
               | 
               | Digressing, but I'm fascinated to see ODA still being
               | referenced, even if only some small part of it
        
       | Lio wrote:
       | Glad to see it's still going.
       | 
       | It amuses me that that a project that started in 1993 is still
       | versioned at 0.9.0 for it's latest stable release.
       | 
       | It's a good reminder that version number don't necissarily denote
       | stability.
        
       | panzi wrote:
       | Wonder if my ansi-img image viewer works in that. Won't compile
       | this from source to test it, but if it's in my Linux distribution
       | I'll do later.
        
         | panzi wrote:
         | Nope, only garbage output: https://imgur.com/a/RVNitFh
         | 
         | Is there a way to configure another terminal font? But it's not
         | just the font, the terminal seems to also crash. At least it's
         | not responsive anymore and has to be closed.
        
       | okflo wrote:
       | I remember somewhen in the 90s, having a 386er Linux system with
       | 8MB RAM, experimenting with twin... So cool, that this project is
       | still alive!
        
       ___________________________________________________________________
       (page generated 2025-06-16 23:01 UTC)