7 ms·

I love TUIs. They are clear, quick and easy to use. Probably because they require straightforward design. I just read the following links to build up foundatio

I love TUIs. They are clear, quick and easy to use. Probably because they require straightforward design. I just read the following links to build up foundation of knowledge first - low-level: http://%CA%9E.cc/irl/term.html http://%CA%9E.cc/irl/term.html https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode.html https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode... https://en.wikipedia.org/wiki/ANSI_escape_code#Colors https://en.wikipedia.org/wiki/ANSI_escape_code#Colors Other libraries: # C, C++, Python and Rust https://github.com/dankamongmen/notcurses https://github.com/dankamongmen/notcurses # Python, more polished presentation - but I cannot judge the technical foundation https://github.com/willmcgugan/rich https://github.com/willmcgugan/rich

nix23 5y ago
True, i worked in a insurance company, the main CRM was a TUI with a Mainframe in the background, fast and reliable as hell/heaven. Then everyone (Management) wanted to go away from mainframe (because it's 60's technology and expensive), so we developed a Java application with a GUI and Oracle in the background..and i was just ashamed about the whole project when it was finished. It was slower for the user, less reliable and counting the dev-cost would gave us 10years of "free" mainframe-time.
- tyingq 5y ago
  I had a similar experience. And it would have been simple to pay attention to tab traversal, field highlighting, key bindings, etc, to have made the new application more familiar and faster. Wasn't to be though.
- sseagull 5y ago
  Similar experience (as a user) at a medium-sized college. The information system (class registration, bursar, etc) could be accessed via a TUI over telnet/ssh. It was amazingly fast, and all the older professors could move around that thing fast as hell, since all the shortcuts were in muscle memory. Force-adding a student to a class could literally take <5s if they had all the numbers. Students could use it, too. And those of us who knew about it would do so, since it was so much better. Then the web frontend came out…
  - megous 5y ago
    Hehe, we also had similar system in university. It was usually accessed over telnet, but in some places at the school, you could still find the real electron tube green (or orange?) text teletype terminal, where the student could sit and access just this system. It was fast in normal times, but you'd still have trouble using it when the class registrations opened, and thousands of students tried to use it at the same time.
    - toast0 5y ago
      > It was fast in normal times, but you'd still have trouble using it when the class registrations opened, and thousands of students tried to use it at the same time. Often the way these things work, the old terminals go slow (sometimes very slow) but work, and the new way times out often making it impossible to make changes, but sometimes you still can, but won't know if they worked.
- habibur 5y ago
  Wanted to hear this. This had been my experience too. But no one on the net seem to talk about it. It was always "we are stuck with mainframe due to politics..." But this isn't about mainframe vs Java. I have a feeling it's about Terminal user interface vs GUI. A modern terminal app, will be just as much fast as those old mainframe apps, is my feeling.
  - mrighele 5y ago
    I don't think it is exactly TUI vs GUI, but more keyboard-first vs mouse-first, i.e. how you interact with it. Granted, Desktop GUI are usually developed mouse-first, but it doesn't have to be that way: if you take windows 98 / windows 2000, you could get everything done more efficiently with a keyboard than with a mouse. Just think about the difference between an app developed specifically for the desktop (mouse) or for mobile (touch): same GUI but completely different programs and experience
    - habibur 5y ago
      Right. Plus responsiveness. Terminal apps have faster response time than GUIs. And when someone is typing like 10 chars per seconds it matters. The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can.
      - eitland 5y ago
        > The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can. Actually I think it is more nuanced than that. Some GUI programs are well optimized for fast keyboard only usage even if you can use point and click. NetBeans, Eclipse, IntelliJ, Sublime Text and VS Code are on top of my mind but even some old web applications used to be quite usable I think.
      - badsectoracula 5y ago
        Terminal apps are running under a GUI terminal for at least two decades now, there isn't really a reason for a GUI application to not be as responsive as a terminal application, it is just that "modern" GUI toolkits being slow. IMO a reason is because nobody seems to bat an eye when faced with a "TUI" made out of lines, boxes and garish colors but if a GUI is made like that it is suddenly ugly so toolkit developers put a ton of effort into shiny looks. But try a GUI made with Win32, Motif, Tk (not Ttk) or even Gtk1 and it'll be as responsive as any terminal application (of course it also depends on the application, there isn't much the GUI can do if the application abuses it or is sluggish for other reasons ).
- wiz21c 5y ago
  I did such a migration. End results : - user security massively increased (they need hardware tokens) - user management is now part of a globalized management system where control access are much stricter than (let's call the dev to add somebody) - it is muuuch easier to find new Java devs; development is now shared between the company (for business knowledge) and another company for the development, diminishing the train factor by a huge amount. - code has been modernized and so is much more easy to audit - SQL database can be queried by armies of cheap data analysis tools - some of the consultants have now much less power to negotiate their salary (less than they were only 3 managing the application :-) ) That were for the positives. Negattives: - Java UI needs much more time to get polished or much better dev's. - Security is now much more administrative. Gone the days of the quick fix in production. - hardware token for security is not vey well handled, incurring a heavy toll on data access (a limitation of our security token, which was unfortunately not seen during project planning) - we had to reproduce all the TUI shortcuts for people to stay productive. Yes, you read that correctly :-)
  - nix23 5y ago
    It sounds you had a much bigger budget than we had ;) BTW, the Mainframe had a sql-database (DB2) and was attached to Active-Directory already, the Reports/Print-jobs where send to a Linux Machine, it was actively maintained and not some old crusty 70's System.
    - rbanffy 5y ago
      The only sad part here is that you didn’t get your own 3278 with beam spring keyboard ;-) People often equate a later fad with “modernisation” when a well architected app can be easy to manage even if written in COBOL and running under CICS. If a person can learn Java, they can learn to read COBOL.
      - nix23 5y ago
        >The only sad part here is that you didn’t get your own 3278 with beam spring keyboard ;-) Hey! I have my beloved HHKB Professional 2 since years :-) >If a person can learn Java, they can learn to read COBOL. Well...well yes! That's true especially the modern one's.
ggerganov 5y ago
For C++, there is also ImTui that I wrote sometime ago: https://github.com/ggerganov/imtui https://github.com/ggerganov/imtui I made a few sample apps with it, such as HN client and a WTF configuration tool. They are both linked in the repo if you are interested. I still want to make some other cool terminal app with it, but haven't found a nice idea yet.
- einpoklum 5y ago
  So, does that actually work in a proper terminal? Or is it only when you have a framebuffer available?
  - ggerganov 5y ago
    > does that actually work in a proper terminal? Yes - all of the examples in the linked repo run in the terminal and are also ported to the Web using Emscripten. > Or is it only when you have a framebuffer available? ImTui creates a framebuffer and renders the scene using ASCII characters into the framebuffer. To create the scene, you can use the entire API of Dear ImGui [0] - it has various options for creating windows, buttons, sliders, tables, checkboxes, colors, etc. You now need to display this framebuffer somehow and also provide input from the keyboard and the mouse. ImTui provides an ncurses interface for this. It uses the ncurses API to render the characters in the terminal and also to grab input from the keyboard and the mouse. Technically, ncurses is an overkill for this application, since ImTui only uses only a very small subset of the ncurses functions. But this was the easiest way to make it work. ImTui can be extended with more interfaces. For example, I made a second one which I call "Emscripten" interface. It's purpose is to provide an API to easily export the framebuffer to the JS layer and to easily grab input back from the JS layer. This way, I can have a single application code that builds and runs both in the terminal and on the web. [0] https://github.com/ocornut/imgui https://github.com/ocornut/imgui
- schaefer 5y ago
  This library looks really fun! Thanks for sharing the link.
KronisLV 5y ago
It feels like we live in a pretty good time for writing TUIs, CLIs and also small self-contained tools (thanks to languages like Go, which have a lot of libraries, are easy to use, but also compile to statically linked executables). What stuck with me was using the Typer library for a Python tool that i wrote: https://typer.tiangolo.com/ https://typer.tiangolo.com/ It made regular shell scripts into a fully fledged CLI with nested commands thanks to just a few decorators that were sprinkled in the source files, as well as the occasional slight signature alteration. Developing a GUI feels awfully complicated in comparison and i'm amazed that there don't seem to be all that many (if any) frameworks for creating GUIs in a similar way - by annotating method calls as actions that correspond to the actual GUI elements and letting some smart parsing logic handle the rest for you. I feel like perhaps the world would be a slightly better place if desktop software could also be distributed as libraries of callable code, where you could automate button presses programmatically and there would be a 1:1 link between what you can do in code and manually.
- dwohnitmok 5y ago
  There is something kind of similar-ish in the GUI space that takes any commandline program and turns it into a simple GUI. https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
- rbanffy 5y ago
  > Developing a GUI feels awfully complicated It’s kind of a language thing. When Visual Basic came out, it’s UI builder was ahead of anything I’ve ever seen on a GUI and more versatile than HyperCard (and much faster). A decent GUI builder attached to an IDE and some nice language support goes a long way. That’s the opposite of the experience you get when using, say, Flutter or React Native. The language is better than BASIC, though.
  - KronisLV 5y ago
    Sadly it seems a thing of the times, perhaps due to the direction the industry has gone in. I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects. There is Swing for Java which had a really nice GUI builder in NetBeans, but the other IDEs are somewhat lacking in comparison and then JavaFX/OpenJFX came out, which didn't integrate quite as nicely and complicated things further. As for .NET, it has always had lovely GUI options, especially with WinForms/WPF in Visual Studio, yet it has always lacked cross platform options for the most part. How we got from being able to drag and drop components to create fully functional GUIs to embedding browsers and creating apps with full webdev stacks locally never ceases to surprise me in a bad way.
a1369209993 5y ago
> http://%CA%9E.cc/irl/term.html http://%CA%9E.cc/irl/term.html Link is broken (malformed); should be (I think) http://xn--rpa.cc/irl/term.html http://xn--rpa.cc/irl/term.html.

nix23 5y ago

True, i worked in a insurance company, the main CRM was a TUI with a Mainframe in the background, fast and reliable as hell/heaven. Then everyone (Management) wanted to go away from mainframe (because it's 60's technology and expensive), so we developed a Java application with a GUI and Oracle in the background..and i was just ashamed about the whole project when it was finished. It was slower for the user, less reliable and counting the dev-cost would gave us 10years of "free" mainframe-time.

tyingq 5y ago
I had a similar experience. And it would have been simple to pay attention to tab traversal, field highlighting, key bindings, etc, to have made the new application more familiar and faster. Wasn't to be though.
sseagull 5y ago
Similar experience (as a user) at a medium-sized college. The information system (class registration, bursar, etc) could be accessed via a TUI over telnet/ssh. It was amazingly fast, and all the older professors could move around that thing fast as hell, since all the shortcuts were in muscle memory. Force-adding a student to a class could literally take <5s if they had all the numbers. Students could use it, too. And those of us who knew about it would do so, since it was so much better. Then the web frontend came out…
- megous 5y ago
  Hehe, we also had similar system in university. It was usually accessed over telnet, but in some places at the school, you could still find the real electron tube green (or orange?) text teletype terminal, where the student could sit and access just this system. It was fast in normal times, but you'd still have trouble using it when the class registrations opened, and thousands of students tried to use it at the same time.
  - toast0 5y ago
    > It was fast in normal times, but you'd still have trouble using it when the class registrations opened, and thousands of students tried to use it at the same time. Often the way these things work, the old terminals go slow (sometimes very slow) but work, and the new way times out often making it impossible to make changes, but sometimes you still can, but won't know if they worked.
habibur 5y ago
Wanted to hear this. This had been my experience too. But no one on the net seem to talk about it. It was always "we are stuck with mainframe due to politics..." But this isn't about mainframe vs Java. I have a feeling it's about Terminal user interface vs GUI. A modern terminal app, will be just as much fast as those old mainframe apps, is my feeling.
- mrighele 5y ago
  I don't think it is exactly TUI vs GUI, but more keyboard-first vs mouse-first, i.e. how you interact with it. Granted, Desktop GUI are usually developed mouse-first, but it doesn't have to be that way: if you take windows 98 / windows 2000, you could get everything done more efficiently with a keyboard than with a mouse. Just think about the difference between an app developed specifically for the desktop (mouse) or for mobile (touch): same GUI but completely different programs and experience
  - habibur 5y ago
    Right. Plus responsiveness. Terminal apps have faster response time than GUIs. And when someone is typing like 10 chars per seconds it matters. The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can.
    - eitland 5y ago
      > The usecase is different between terminal vs GUI. Where in GUI you look - choose - decide and click. And in terminal you blindly storm on the keyboard as fast as you can. Actually I think it is more nuanced than that. Some GUI programs are well optimized for fast keyboard only usage even if you can use point and click. NetBeans, Eclipse, IntelliJ, Sublime Text and VS Code are on top of my mind but even some old web applications used to be quite usable I think.
    - badsectoracula 5y ago
      Terminal apps are running under a GUI terminal for at least two decades now, there isn't really a reason for a GUI application to not be as responsive as a terminal application, it is just that "modern" GUI toolkits being slow. IMO a reason is because nobody seems to bat an eye when faced with a "TUI" made out of lines, boxes and garish colors but if a GUI is made like that it is suddenly ugly so toolkit developers put a ton of effort into shiny looks. But try a GUI made with Win32, Motif, Tk (not Ttk) or even Gtk1 and it'll be as responsive as any terminal application (of course it also depends on the application, there isn't much the GUI can do if the application abuses it or is sluggish for other reasons ).
wiz21c 5y ago
I did such a migration. End results : - user security massively increased (they need hardware tokens) - user management is now part of a globalized management system where control access are much stricter than (let's call the dev to add somebody) - it is muuuch easier to find new Java devs; development is now shared between the company (for business knowledge) and another company for the development, diminishing the train factor by a huge amount. - code has been modernized and so is much more easy to audit - SQL database can be queried by armies of cheap data analysis tools - some of the consultants have now much less power to negotiate their salary (less than they were only 3 managing the application :-) ) That were for the positives. Negattives: - Java UI needs much more time to get polished or much better dev's. - Security is now much more administrative. Gone the days of the quick fix in production. - hardware token for security is not vey well handled, incurring a heavy toll on data access (a limitation of our security token, which was unfortunately not seen during project planning) - we had to reproduce all the TUI shortcuts for people to stay productive. Yes, you read that correctly :-)
- nix23 5y ago
  It sounds you had a much bigger budget than we had ;) BTW, the Mainframe had a sql-database (DB2) and was attached to Active-Directory already, the Reports/Print-jobs where send to a Linux Machine, it was actively maintained and not some old crusty 70's System.
  - rbanffy 5y ago
    The only sad part here is that you didn’t get your own 3278 with beam spring keyboard ;-) People often equate a later fad with “modernisation” when a well architected app can be easy to manage even if written in COBOL and running under CICS. If a person can learn Java, they can learn to read COBOL.
    - nix23 5y ago
      >The only sad part here is that you didn’t get your own 3278 with beam spring keyboard ;-) Hey! I have my beloved HHKB Professional 2 since years :-) >If a person can learn Java, they can learn to read COBOL. Well...well yes! That's true especially the modern one's.

ggerganov 5y ago

For C++, there is also ImTui that I wrote sometime ago: https://github.com/ggerganov/imtui https://github.com/ggerganov/imtui I made a few sample apps with it, such as HN client and a WTF configuration tool. They are both linked in the repo if you are interested. I still want to make some other cool terminal app with it, but haven't found a nice idea yet.

einpoklum 5y ago
So, does that actually work in a proper terminal? Or is it only when you have a framebuffer available?
- ggerganov 5y ago
  > does that actually work in a proper terminal? Yes - all of the examples in the linked repo run in the terminal and are also ported to the Web using Emscripten. > Or is it only when you have a framebuffer available? ImTui creates a framebuffer and renders the scene using ASCII characters into the framebuffer. To create the scene, you can use the entire API of Dear ImGui [0] - it has various options for creating windows, buttons, sliders, tables, checkboxes, colors, etc. You now need to display this framebuffer somehow and also provide input from the keyboard and the mouse. ImTui provides an ncurses interface for this. It uses the ncurses API to render the characters in the terminal and also to grab input from the keyboard and the mouse. Technically, ncurses is an overkill for this application, since ImTui only uses only a very small subset of the ncurses functions. But this was the easiest way to make it work. ImTui can be extended with more interfaces. For example, I made a second one which I call "Emscripten" interface. It's purpose is to provide an API to easily export the framebuffer to the JS layer and to easily grab input back from the JS layer. This way, I can have a single application code that builds and runs both in the terminal and on the web. [0] https://github.com/ocornut/imgui https://github.com/ocornut/imgui
schaefer 5y ago
This library looks really fun! Thanks for sharing the link.

KronisLV 5y ago

It feels like we live in a pretty good time for writing TUIs, CLIs and also small self-contained tools (thanks to languages like Go, which have a lot of libraries, are easy to use, but also compile to statically linked executables). What stuck with me was using the Typer library for a Python tool that i wrote: https://typer.tiangolo.com/ https://typer.tiangolo.com/ It made regular shell scripts into a fully fledged CLI with nested commands thanks to just a few decorators that were sprinkled in the source files, as well as the occasional slight signature alteration. Developing a GUI feels awfully complicated in comparison and i'm amazed that there don't seem to be all that many (if any) frameworks for creating GUIs in a similar way - by annotating method calls as actions that correspond to the actual GUI elements and letting some smart parsing logic handle the rest for you. I feel like perhaps the world would be a slightly better place if desktop software could also be distributed as libraries of callable code, where you could automate button presses programmatically and there would be a 1:1 link between what you can do in code and manually.

dwohnitmok 5y ago
There is something kind of similar-ish in the GUI space that takes any commandline program and turns it into a simple GUI. https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
rbanffy 5y ago
> Developing a GUI feels awfully complicated It’s kind of a language thing. When Visual Basic came out, it’s UI builder was ahead of anything I’ve ever seen on a GUI and more versatile than HyperCard (and much faster). A decent GUI builder attached to an IDE and some nice language support goes a long way. That’s the opposite of the experience you get when using, say, Flutter or React Native. The language is better than BASIC, though.
- KronisLV 5y ago
  Sadly it seems a thing of the times, perhaps due to the direction the industry has gone in. I recall creating GUIs in Lazarus/FreePascal was really easy and an enjoyable experience, however there are so few libraries and integrations for it, that it's a non starter for new projects. There is Swing for Java which had a really nice GUI builder in NetBeans, but the other IDEs are somewhat lacking in comparison and then JavaFX/OpenJFX came out, which didn't integrate quite as nicely and complicated things further. As for .NET, it has always had lovely GUI options, especially with WinForms/WPF in Visual Studio, yet it has always lacked cross platform options for the most part. How we got from being able to drag and drop components to create fully functional GUIs to embedding browsers and creating apps with full webdev stacks locally never ceases to surprise me in a bad way.

a1369209993 5y ago

> http://%CA%9E.cc/irl/term.html http://%CA%9E.cc/irl/term.html Link is broken (malformed); should be (I think) http://xn--rpa.cc/irl/term.html http://xn--rpa.cc/irl/term.html.