Notcurses 2.4 | Hacker News Reader

Notcurses 2.4

github.com

140 pointsmarcodiego39 comments

That demo is _amazing_. It has to be by far one of the best uses for the terminal I have seen in a long time! Impressive what that text console can do!

While watching the demo, I got flashbacks from the talk from Gary Bernhardt, 'A Whole New World'[1].

[1] https://www.destroyallsoftware.com/talks/a-whole-new-world

Is there a demo in this link? I’m not seeing it.

https://www.youtube.com/watch?v=dcjkezf1ARY found on the main page

Or run it locally. Quality may vary based on terminal capabilities (for example, iTerm2 is sum+ rgb+ quad+ versus Terminal.app).

$ brew install notcurses && notcurses-demo

> The terminal is now extensively (but efficiently) queried on startup. Some properties are derived from the results.

> Eventually, this will be expanded to eliminate our reliance on TERM and dependence on terminfo.

So they're doing feature detection? I didn't know that was possible for terminals, but if it is then it does seem like a nice step forward. Of course, it seems like such an obvious improvement that I'm curious why it hasn't happened before (i.e. why is everyone else still depending on TERM?)

Simple reason - there was no way to do feature detection reliably on many a terminal, which also makes me wondering how the hell are they going to make it reliable, unless they simply decide to not support many terminals.

From the change log:

> Numerous patches were submitted to upstream terminals to support this functionality.

That's still going to lose the long tail

Sure, then you just fall back to whatever best effort approach you were using before.

At some point, the number of people on that tail will be smaller than the number of people with an incorrectly setup $TERM, for a net gain in effective portability.

It’s often so easy not to submit these kinds of changes. But 10 years later you still don’t have them.

Seems like a long wait now but is worth it later.

They won't support that many terminal types. This is what has been done in this situation for decades.

The key is ending the device query string with DA1 aka "Primary Device Attributes", which literally every terminal i've managed to test with responds to. Guaranteed that one answer, you completely avoid nasty timeouts. This is required for even VT100 conformance, so it can be expected on even hardware terminals (though not necessarily those outside the DEC family).

I tested over 24 terminals personally, and the only one I found which didn't respond to DA1 was Terminology from EFL, which crashed forty ways to a friday anyway so who really cares?

i'm glad you asked, as i'm hella proud of this entire system. you can check the code at:

https://github.com/dankamongmen/notcurses/blob/master/src/li...

and

https://github.com/dankamongmen/notcurses/blob/master/src/li...

i mean, it's tricky, and you have to think some things out pretty carefully, but it works. everything hinges on DA1.

many props to @dknl of the "foot" terminal emulator, who just kicks ass in general and first turned me on to DA1:

you can see the history in bugs starting with https://github.com/dankamongmen/notcurses/issues/1469

hack on!

It's good to see a passion project that is blatantly being done just for the fun of it and sharing with 0 concern what a corporation might think.

Something like this has been sorely needed. terminfo has simply failed to keep up with modern terminal features, and propagating new terminfo database entries to remote systems has been a challenge. The combination has been a stagnation of terminal programs combined with hacky ad-hoc feature detection or non-TERM-based, non-portable feature signaling.

Next I want to see Crysis running in a terminal.

Actually that raises an interesting question. Can OpenGL work in Notcurses?

I don't see why not, software renderers exist, just point it at a "surface" made from "pixels" which are actually block characters of different colors.

One thing I once did was capture the screen and stream it. On the other side I watched it using mpv with libcaca as the output.

Graphical desktop on the terminal.

>Can OpenGL work in Notcurses?

Yes, this is quite easy to do with OSMesa, or with EGL_KHR_surfaceless_context. With the latter it will be hardware accelerated too.

The guy that does the releases must of gone to the University of Alabama Roll tide roll is what you say at one of their football games to cheer them on. Or maybe his dad went to University of Alabama. Roll tide!

There is a dedication for this release:

the 2.4.0 release of Notcurses is dedicated with loving memory to Gregory Allen Black, aka Pa Dank, 1949–2021. give 'em shit in the afterlife, dad. don't take any guff from those fucking swine. hearts alive. roll tide roll.

He went to The Georgia Institute of Technology actually. Nick was a legend in the College of Computing even as an undergrad.

While I do not know, I concur with it likely being his dad who is the University of Alabama alumnus

> Nick was a legend in the College of Computing even as an undergrad.

Why?

i am indeed a yellow jacket several times over. pa dank did not attend the university of alabama at tuscaloosa, nor any other institute of higher learning, but as anyone who knows SEC fans can tell you, attendance is not required for fandom. his roll tides were valid.

alas, it's pretty hard to get it up for GT when you just got waxed by a directional middle school from illinois.

fine, very fine, a new/better fb-terminal is a good thing;

still i wonder if this thing couldn't embed itself into a bash-process and serve tui frames with a scriptable curses api so that you could, for ex, have some tabs and buttons and graphs on a system status app

it could bring inversion of control to node and any kind repl .. so that instead of away from a term-info and term-cap standard, one would move toward curses as an acessible tui/gui metaphor, or at least toward something that makes sense without constant apologies for the past.

maybe i'm not using the right words, but it seems to me that hacking this up so it can be stuck into bash so that its api appears like any other language extension would make notcurses a highly desirable dependency for just about any project!

I like the very entertaining and thorough documentation. However this just shows that FOSS GUI programming is in such a dire state that people have to resort to TUIs because it is so much easier to develop for and to deploy.

Is that really a FOSS issue?

The abandonment of established interfaces happens on purpose on proprietary platforms to force customers to upgrade. The abandonment of established interfaces happens on FOSS platforms equally as frequent without any obvious purpose.

I'm not sure what you mean? I would suggest to take a look at the release notes for the newest Qt or GTK for example, if you want to see what the purpose of various changes are.

> The abandonment of established interfaces happens on FOSS platforms equally as frequent without any obvious purpose.

My laptop literally has CDE installed on it, using motif, indistinguishable from how it looked and acted decades ago. GTK is not the world.

There are reasons for the changes in GTK, though you may not agree with them, if you are confused about some then feel free to check the release notes. Or you can ask and I may be able to explain.

But if you don't have any issues with motif and it works for you then that's great.

I was just using GTK as (the poster child of) a toolkit that does change things. It's not my preference at all, but in its own world it's fine.

The choice between TUI vs GUI is far from that simple. It’s too reductive to say that TUIs are common in FOSS because the state of GUI programming is in such disarray.

TUIs are easier to deploy and the GUI landscape is fragmented. But the only reason why TUIs are common is because the users are comfortable with them. I think that the proportion of users who are comfortable at a command line is much higher with Linux, BSD, or even macOS users than other OSs.

If the users weren’t comfortable using a CLI or TUI, there would be a bigger push to unify the GUI landscape. Otherwise no programs would get written because they wouldn’t be used.

Maybe I should dust off my Turbo Vision and Clipper manuals.

There is a lack of good documentation but that is not the whole story. Both the Gnome and KDE desktops have a huge amount of software running on them despite the barriers.

Writing for a modern native GUI strongly favours an OO language like a c#/Dart/Swift/Vala/Java. And it isn't just the language but the ABI. A java or gobject or c++ gui library doesn't always map well onto another language. There is a lot of code out there where adding a GUI isn't trivial or fun. Tk used to fill this gap a bit but it fell out of fashion.

It is trivial to output formatted text to a terminal from any language with some ANSI escape codes. It also easy to do templating and html to provide a web interface.

An HTML server is a pretty good UI for a lot of things. That is if a text config file is insufficient.

Also, terminal apps are great! Where would I be without a decent terminal text editor? Certainly not SSH'd into some cloud instance.

This looks cool, gonna kick the tyres and take it for a spin

just brew installed it and ran their demo.

impressive!

41% rust :thumbup:

> 41% rust :thumbup:

which is only a wrapper library/bindings.

Blessings?

Reply on news.ycombinator.com