I just read the following links to build up foundation of knowledge first - low-level:
http://%CA%9E.cc/irl/term.html
https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
Other libraries:
# C, C++, Python and Rust
https://github.com/dankamongmen/notcurses
# Python, more polished presentation - but I cannot judge the technical foundation
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.
- 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 :-)
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…
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.
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.
What stuck with me was using the Typer library for a Python tool that i wrote: 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.
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.
Link is broken (malformed); should be (I think) http://xn--rpa.cc/irl/term.html.
https://sw.kovidgoyal.net/kitty/keyboard-protocol/ is a very promising step on this direction. Maybe next time I have to work on a TUI I will look into it.
Sure, you can write a TUI library that allows you to interact with "idealised terminal of choice", but I'd prefer one that works with one of the serial terminals I actually have, somewhere, around the place.
Nowadays when making a quick interface I tend to use a web-based interface -- while they are much heavier it's fairly easy to make fully blind accessible interfaces, I (very briefly) looked to see if any terminal based libraries supported anything similar, and the only thing which seems to be trying is emacs, with emacsspeak (which I've heard good things about but haven't tried, as I'm not an emacs user).
Some curses programs work reasonably well with screen readers (e.g. Mutt and WeeChat). One useful way to make them more accessible is to put the hardware cursor somewhere useful, even if hidden. Mutt puts it on the same line as the currently-selected message, and if braille_friendly is set, onto the first line of message content when opening one.
WeeChat puts it on the input line. Where this goes wrong is when trying to use fset, where I have no way to move it to the list of options.
https://kannel.org/download/1.4.5/userguide-1.4.5/userguide....
I don't think that this is inherent to ncurses but to any UI programming. Keeping state on the UI can be "simple" until is not.
Thanks for the idea, I'll give it a try!
Access Denied - Sucuri Website Firewall Block reason: Access from your Country was disabled by the administrator.
In case someone else experience the same and wants an alternate link: http://web.archive.org/web/20210531163620/https://invisible-...
So, the mirrored copy of this article would be: https://invisible-mirror.net/ncurses/ncurses-intro.html
Thanks for that mirror, I occasionally use the lynx web browser that is also hosted there and being blocked has always been a problem.
https://github.com/incanus/fari
Since then, however, I’ve switched to the Min browser. But it was super empowering to make a console-based interface and I’m looking forward to trying it again soon.
I enjoy r/unixporn (it's actually sfw), they LOVE console apps there, everything from music to email to file manager to everything console!
There are also a few modern terminal emulators that are doing some pretty fun stuff with the terminal, some examples are alacritty, kitty and hyper
The mouse support is excellent, assuming your terminal emulator supports the features it needs. (Alacritty does, but iTerm2 doesn't seem to send right clicks to the program.) Pretty much everything can be clicked and right-clicked, you can even scroll (although I find it scrolls too fast to be useful).
I listen to most of my music through musikcube and ncspot https://github.com/hrkfdn/ncspot these days.
https://dump.cy.md/7065a236c07f22558d3f1422c986a243/16303431...
https://webcache.googleusercontent.com/search?q=cache:6a4RZk...
I dispute that point. Firstly, because TUIs and GUIs were developed pretty much in parallel, as far as I‘m aware. But secondly (and more importantly), because TUIs fill a different niche and follow a different philosophy to GUIs.
TUIs are primarily intended for environments where GUIs are either not available (e.g. SSH), unnecessary (e.g. servers), or overkill (e.g. very old computers). In terms of design and UX philosophy, they are much more concentrated on keybased rather than mousebased interaction, and bring their own set of conventions that are markedly different from GUI design philosophy.
So, while you are entitled not to like TUIs (they can be difficult to work with), calling them a bad emulation of GUIs really misses the point.
You'd have to be using a very old computer considering Windows 3.0 worked even on an original IBM PC. Though granted, you needed at least a 386 for it to be usable.
Chances are your GUI toolkit is too bloated, but that is the fault of the toolkit you chose, not GUIs themselves - use a more lightweight toolkit.
> In terms of design and UX philosophy, they are much more concentrated on keybased rather than mousebased interaction
This is up to the application, there is nothing that forbids GUIs to be fully keyboard controlled (in addition to mouse of course).
> and bring their own set of conventions that are markedly different from GUI design philosophy.
Pretty much every TUI either has its own set of conventions or mimics established GUIs or a mix of both, so not really.
