notcurses VS jexer

> The only reason we don't have animation frameworks for the terminal is because it's not possible

https://nick-black.com/dankwiki/index.php/Notcurses

Notcurses. Install it and run notcurses-demo to be suitably impressed.

Same for me, I would be much more motivated if there was something like textual for Rust. Given the capability of terminal emulators now I think Rust is lacking behind in the TUI field. Just checkout what can be done with something like notcurses

On the application side of rendering, see notcurses, it is at the leading edge: https://github.com/dankamongmen/notcurses

Other TUI libraries of note: https://github.com/dankamongmen/notcurses/blob/master/doc/OT...

The broader world probably knows him best for the terminal handling library Notcurses[1] and a lot of telling terminal emulator authors to get their shit together.

I’ve had his grad-school project libtorque[2] (HotPar ’10), an event-handling and scheduling library, on my to-read list for years, but I can’t seem to figure out how it accomplishes the interesting things it does.

[1] https://nick-black.com/dankwiki/index.php/Notcurses, https://github.com/dankamongmen/notcurses/

[2] https://nick-black.com/dankwiki/index.php/Libtorque

In XTerm, this (rightly) makes no difference. In Foot and Contour however, you still end up a line resp. a screen below where you started, if now with the correct horizontal position.

So it seems to me like what you want should work by default, except it doesn’t.

It should be possible to instead just treat the whole thing as a graphical overlay (by computing or directly asking for the character cell size, as Kirill Panov rightly admonishes me is possible with XTWINOPS) without touching the cursor; that’s what the “sixel scrolling” setting (DECSDM) is supposed to do. Then you can just manually move the cursor forward however many positions after you’re done drawing.

Except apparently the DEC manual (the VT330/340 one above) and DEC hardware contradict each other as to which setting of DECSDM (set or reset) corresponds to which scrolling state (enabled or disabled), and XTerm has implemented it according to the manual not the VT3xx[1,2,3]—then most other emulators followed suit[4]—then XTerm switched to following the hardware[5,6] (unless you and that’s what I’m seeing on my machine right now. So now you need to check if you’re on XTerm ≥ 369 or not[7]. If I’m reading the Notcurses code right, other terminals have followed suit[8].

Again, ouch.

P.S. It seems DEC had an internal doc for how their terminals should operate (DEC STD 070) [9]. It does not document DECSDM at all.

[1] https://github.com/wez/wezterm/issues/217#issuecomment-86449...

[2] https://github.com/hackerb9/lsix/issues/41

[3] https://github.com/dankamongmen/notcurses/issues/1782

[4] https://github.com/arakiken/mlterm/pull/23

[5] https://invisible-island.net/xterm/xterm.log.html#xterm_369

[6] https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-T...

[7] https://github.com/dankamongmen/notcurses/commit/0918fa251e2... (the correct version cutoff is 369 not 359, the patch contains a now-fixed bug)

[8] https://github.com/dankamongmen/notcurses/blob/master/src/li... (look for mentions of invertsixel)

[9] http://www.bitsavers.org/pdf/dec/standards/EL-SM070-00_DEC_S...

And there's also the notcurses library:

Very interesting! I was thinking literally yesterday about a TUI/GUI Qubes type concept, maybe also applicable for industrial type data diodes.

I did something like that once. Is your project online somewhere? I'm always curious what else is going on. :)

When I transliterated from D to Java around 2015, Java wasn't quite the "uninteresting" language it is perceived to be today. But all along I had hoped others might pick up some tricks, and put some notes on porting it here. Yet Java's been a pretty solid workhorse for me, and having the Swing GUI to test on was a godsend actually once I got into images.

If you code in Java, and like TUI (console type applications), then you might enjoy Jexer: https://gitlab.com/klamonte/jexer

I started Jexer in 2013, and off-and-on it's gotten better. I think my favorite part has been crossing paths with other terminal emulator ecosystem folks over the last few years. This release brings a few prettified effects inspired by other projects that you are all hopefully quite familiar with (notcurses, chafa, and vtm):

* Translucent windows, including images under/over each other and text.

* Animated/pulsing text

* Animated gifs

* A new XtermVideoPlayer example that uses ffmpeg/JavaCV to play movies inside a text-draggable window. (No audio though.)

* New button styles: round, diamond, left/right arrows. The button ends and shadows are drawn with images so specific font support is not required.

* A _much_ faster and _much_ higher quality sixel encoder.

* Different window border styles: single, double, none, and rounded corners.

* A femme theme option.

Some screenshots are posted here: https://twitter.com/AutumnMeowMeow/status/148922891703050240...

It's on maven and Sourceforge.

If you code in Java, and like TUI (console type applications), and enjoy transfemme in-jokes, then you might also enjoy jexer.

A path that started in the BBS era and is currently bringing DOOM to Xterm. And ironically, there is much better support for this now than there ever was for RIPscript.

Story time: when I first posted Jexer to Reddit, people were all "twin does that". No, it does not. twin does not pass vttest. twin has almost no widgets. twin does not support images at all, it does not multiplex images, it does not multihead images, and it does not play videos (a bit too slowly but still) in a text draggable/resizable window that could be part of a larger system. mpv/mplayer doesn't do those things either. In fact, the only two projects I know of that can do these kinds of tricks are Jexer and notcurses. (And notcurses is hella faster and great, and I would have used it in 2013 when I started Jexer, but it didn't exist then.)

One way to do translucent windows. - Inspired by notcurses

foot is great, dnkl is great. It's so far the fastest sixel-supporting terminal I've got to test XtermDOOM on. (I run iTerm2-based images against wezterm.)

It parses them, but then reduces to the 8/16 ANSI colors. Which makes translucent TUI windows not work. :(