5 ms·

Ncurses has always been on my list of cool things I wanted to learn but couldn't invest the time to actually build something with. Then I found Textual (Python

Ncurses has always been on my list of cool things I wanted to learn but couldn't invest the time to actually build something with. Then I found Textual (Python library, https://textual.textualize.io/ https://textual.textualize.io/) which feels like its modern and prettier child. Not gonna lie, it's still not a turnkey solution that transformed my clumsy scripts into a beautiful TUI without work but it's close!

autoexec 2y ago
It's kind of crazy how much work it takes to get an interface on the level of ancient software to work on modern systems.
- echoangle 2y ago
  It took even more work to get it to work on the ancient systems though, right?
  - shakna 2y ago
    Turbo TUIs were easy to make. You could make them asynchronous, non-blocking, include sound, and if you were using Borland's C compiler, all of that was built-in for you. They probably went to efforts to make it work an ancient system. But you really didn't have to.
    - copperx 2y ago
      Turbo TUIs we're beautiful to my 13 year old self and still are to me.
    - ChickeNES 2y ago
      Someone modernized Turbo Vision: https://github.com/magiblot/tvision https://github.com/magiblot/tvision
      - _mlbt 2y ago
        It’s also included with FreePascal if you prefer the Pascal flavor of Turbo Vision. It even comes with a fully featured clone of the Turbo Pascal IDE.
  - rerdavies 2y ago
    Speaking from experiences, it's kind of amazing how much work you have to do in order to talk to a modern VGA or xterm terminal using ncurses. You really feel each layer of crust that ncurses has accumulated over the entire history of the personal computer since it was first written in order to allow people to play rogue on their personal VT-100 terminals. Tunneling through the layer of crust accumulated in order to support Unicode (several layers of crust as Unicode evolved) was probably the most interesting of all. https://rerdavies.github.io/nwindows/ https://rerdavies.github.io/nwindows/
    - trollbridge 2y ago
      Generating ANSI escape sequences to program a display is significantly more clunky than just directly addressing the text framebuffer that existed in early PCs (and often still does, albeit emulated by the GPU). You have an 80x25 array of words. Low word is the ASCII character, high word’s low nibble the foreground colour, high nibble the background. Character set is fixed to CP437 which had a reasonable choice of graphics, math symbol, and other characters. A competent programmer could fit the whole charset in their head and easily write a TUI from scratch in a day. But they didn’t need to: plenty of great libraries existed.
      - 2mlWQbCK 2y ago
        One thing that made an impression on me when reading the 1991 Blue Book About GW-BASIC (1991) earlier this year was the chapter on making a text-mode user interface, that recommended drawing a characters+attributes interface 80x25 using an external editor, save that as a raw 4 kB file, and then from the BASIC program just BLOAD the file straight into graphics memory to render the screen in one line. Everything is so much easier when you have standardized hardware instead of layers upon layers of abstractions supporting all sorts of weird things, like we have to put up with this century. https://github.com/robhagemans/hoard-of-gwbasic https://github.com/robhagemans/hoard-of-gwbasic
        rerdavies 2y ago
        It is, of course, a very simple system if you never plan to render anything that isn't an ASCII character, or a value in US dollars. Things get complicated pretty quickly in DOS/Windows world once you wander outside the ASCII character set range. And there are strange and wonderful things in EGA and VGA hardware (standard, non-standard, and outright genius-level hackery) that are ridiculously complicated that are hardly ever used if you are fortunate enough to be an American who never uses anything but DOS.
- mbirth 2y ago
  I’ve happily used python-dialog, a wrapper for dialog (and dialog-compatible alternatives) which provides the very basics but is extremely easy to work with. https://pythondialog.sourceforge.io/ https://pythondialog.sourceforge.io/
xavierog 2y ago
> Not gonna lie, it's still not a turnkey solution that transformed my clumsy scripts into a beautiful TUI without work but it's close! Can you elaborate on that? Are your "clumsy scripts" written in Python, shell or another language? Have you tried Textual-based tools like Trogon [1] and Moulti? [2] [1] https://github.com/Textualize/trogon https://github.com/Textualize/trogon [2] https://moulti.run/ https://moulti.run/
- vladsanchez 2y ago
  Wow, I love TUIs but never delved into researching Textualize forks/alternatives. Thanks a lot for sharing these, especially Trogon, which I think is a clever idea with high ROI.
- cranium 2y ago
  Rereading myself it looks like I'm blaming Textual for being too much work to use but it's not the case! I wanted to say that powerful (T)UIs have inherent complexity coming with the territory: async, events, UI thread, reactivity, render frames, debugging... Works great, but it's UI work on top of the script.

autoexec 2y ago

It's kind of crazy how much work it takes to get an interface on the level of ancient software to work on modern systems.

echoangle 2y ago
It took even more work to get it to work on the ancient systems though, right?
- shakna 2y ago
  Turbo TUIs were easy to make. You could make them asynchronous, non-blocking, include sound, and if you were using Borland's C compiler, all of that was built-in for you. They probably went to efforts to make it work an ancient system. But you really didn't have to.
  - copperx 2y ago
    Turbo TUIs we're beautiful to my 13 year old self and still are to me.
  - ChickeNES 2y ago
    Someone modernized Turbo Vision: https://github.com/magiblot/tvision https://github.com/magiblot/tvision
    - _mlbt 2y ago
      It’s also included with FreePascal if you prefer the Pascal flavor of Turbo Vision. It even comes with a fully featured clone of the Turbo Pascal IDE.
- rerdavies 2y ago
  Speaking from experiences, it's kind of amazing how much work you have to do in order to talk to a modern VGA or xterm terminal using ncurses. You really feel each layer of crust that ncurses has accumulated over the entire history of the personal computer since it was first written in order to allow people to play rogue on their personal VT-100 terminals. Tunneling through the layer of crust accumulated in order to support Unicode (several layers of crust as Unicode evolved) was probably the most interesting of all. https://rerdavies.github.io/nwindows/ https://rerdavies.github.io/nwindows/
  - trollbridge 2y ago
    Generating ANSI escape sequences to program a display is significantly more clunky than just directly addressing the text framebuffer that existed in early PCs (and often still does, albeit emulated by the GPU). You have an 80x25 array of words. Low word is the ASCII character, high word’s low nibble the foreground colour, high nibble the background. Character set is fixed to CP437 which had a reasonable choice of graphics, math symbol, and other characters. A competent programmer could fit the whole charset in their head and easily write a TUI from scratch in a day. But they didn’t need to: plenty of great libraries existed.
    - 2mlWQbCK 2y ago
      One thing that made an impression on me when reading the 1991 Blue Book About GW-BASIC (1991) earlier this year was the chapter on making a text-mode user interface, that recommended drawing a characters+attributes interface 80x25 using an external editor, save that as a raw 4 kB file, and then from the BASIC program just BLOAD the file straight into graphics memory to render the screen in one line. Everything is so much easier when you have standardized hardware instead of layers upon layers of abstractions supporting all sorts of weird things, like we have to put up with this century. https://github.com/robhagemans/hoard-of-gwbasic https://github.com/robhagemans/hoard-of-gwbasic
      - rerdavies 2y ago
        It is, of course, a very simple system if you never plan to render anything that isn't an ASCII character, or a value in US dollars. Things get complicated pretty quickly in DOS/Windows world once you wander outside the ASCII character set range. And there are strange and wonderful things in EGA and VGA hardware (standard, non-standard, and outright genius-level hackery) that are ridiculously complicated that are hardly ever used if you are fortunate enough to be an American who never uses anything but DOS.
mbirth 2y ago
I’ve happily used python-dialog, a wrapper for dialog (and dialog-compatible alternatives) which provides the very basics but is extremely easy to work with. https://pythondialog.sourceforge.io/ https://pythondialog.sourceforge.io/

xavierog 2y ago

> Not gonna lie, it's still not a turnkey solution that transformed my clumsy scripts into a beautiful TUI without work but it's close! Can you elaborate on that? Are your "clumsy scripts" written in Python, shell or another language? Have you tried Textual-based tools like Trogon [1] and Moulti? [2] [1] https://github.com/Textualize/trogon https://github.com/Textualize/trogon [2] https://moulti.run/ https://moulti.run/

vladsanchez 2y ago
Wow, I love TUIs but never delved into researching Textualize forks/alternatives. Thanks a lot for sharing these, especially Trogon, which I think is a clever idea with high ROI.
cranium 2y ago
Rereading myself it looks like I'm blaming Textual for being too much work to use but it's not the case! I wanted to say that powerful (T)UIs have inherent complexity coming with the territory: async, events, UI thread, reactivity, render frames, debugging... Works great, but it's UI work on top of the script.