WITH THAT SAID, Notcurses can now acquire the default background from the terminal (this was not true when I wrote the book, sigh), and I fully support @akkartik's approach given this fact. Using NCALPHA_HIGHCONTRAST together with explicit reproduction of the user's chosen background is a complete and general solution to this problem, and I really ought update the book. Thanks, @akkartik!
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.
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:
I watched the video and was very impressed -kudos!
I have a couple of questions that hopefully you haven't answered elsewhere. I looked over the github for your project but it was 3am so I might have missed it they're answered there.
1)I saw that this can be run over ssh -but in a graphical terminal. Does this require the client terminal to be running on something like X or Wayland or would it work from a regular console?
2)I didn't noticed any BSD ports, is this an afterthought (ie if you don't use BSD you wouldn't port it) or do you mostly lean into a lot of Linux specific system calls?
Anyway -the video was very intense in a great way and it's good to see a next next generation curses!
1) you can run from a regular console. if it's a linux framebuffer console and you're local, it'll even use the framebuffer to draw graphics. if you're on a pure VGA console, or ssh'd from the framebuffer console, that obviously won't work, alas.
2) there is an up-to-date port in the Ports Collection (i maintain it), and DragonFly imports things from time to time (they're running a pretty old 2.2.2 iirc). nothing on NetBSD or OpenBSD but i'd love to be there, and would be happy to take PRs!
Surprised I Need Air didn't get you copyright striked. Such a great song.
This looks very well done, probably the best library for this in existence judging from the video. I'll have to take a closer look later, thanks for sharing the video link.
i TA'd the intro to computer science class at Georgia Tech, taught using Java 1.1.7, back in 1999, and have used very little java since. at the time, it was not a particularly pleasant environment, though i suppose few things were.
more concretely, Autumn Lamonte's Jexer (https://jexer.sourceforge.io/) is a far better solution for Java, better than any wrapper of Notcurses could ever be due to its rich integration with the language and its expansive APIs.
beyond that, i authentically don't ever want to have to deal with bugs about a java port.
I wonder if the bitmap support is limited to terminals which support sixels.
I also wonder what is the CPU price of the raster graphics, flying windows, etc — I suppose it's depends heavily on the terminal emulator? Which of them performed best?
no, Notcurses supports both Sixel and the Kitty protocol (indeed, i proposed https://github.com/kovidgoyal/kitty/issues/3809, which drastically cut down on the bandwidth necessary for certain operations), in addition to the Linux framebuffer console (where we use a direct mmap of the framebuffer). WezTerm recently added support for the Kitty protocol, and indeed Notcurses was used to validate that work: https://github.com/wez/wezterm/issues/986. i sat down to design the ultimate terminal graphics protocol, and it ended looking so much like Kitty's that i resolved to just advocate terminals pick up that one: https://nick-black.com/dankwiki/index.php?title=Spriteful_TE...
in general, kitty and alacritty are both pretty damn fast. xterm lags behind, and really lags behind if you're using truetype fonts. wezterm wasn't included in these samples; my general impression is that it's behind them both, but catching up quickly. Konsole and VTE-derived terminals are well behind the Kitty/Alacritty forerunners.
if you're using wayland, foot is a masterpiece.
Appendix B of the notcurses book (https://nick-black.com/htp-notcurses.pdf) entitled "Wherein shade is thrown at terminal emulators..." explores this subject in more depth, though still not as completely as i'd have liked.
Taking a quick look, I don't want to besmirch anyone else's efforts, and both of these projects look great. libtickit appears to be missing any kind of multimedia/pixel-based approach along the lines of Notcurses's ncvisual -- I'm not sure about CPPurses, but that one being written in C++ would seem to exclude pure C programs (obviously not if it's using POD structures etc).
Both look like good efforts, and there's plenty of room for more than one project in this space. I wish them both luck!
