[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#950492: ITP: notcurses -- Character-mode graphics and TUI library



Very cool!  (and apologies for missing it in the readme)

I have been rather annoyed at the increasing number of curses-like
libraries that only work with ANSI terminals.  It is refreshing to see a
new one that properly supports terminfo!

I own a number of actual serial terminals from the 80s and 90s and
actively use them in various projects.  They of course know nothing of
Unicode (another challenge) or color, but otherwise are still quite
functional.

Best,

John

On Mon, Feb 03 2020, Nick Black wrote:

> Your questions are answered in the README.md, I believe:
>
> https://github.com/dankamongmen/notcurses
>
> Yes, it is powered by (and requires) Terminfo. It ought work, more or less,
> with all terminals capable of cursor-based addressing ("cup" Terminfo
> capability). It quantizes color down at the moment in the absence of 24bit
> RGB support, but I plan to issue perfect palettes for terminals with the
> "ccc" capability Real Soon Now.
>
> On Mon, Feb 3, 2020, 19:47 John Goerzen <jgoerzen@complete.org> wrote:
>
>> Hi Nick,
>>
>> This is interesting.  Out of curiosity, does notcurses still support
>> terminfo and provide a functional implementation on non-ANSI terminals?
>> (eg, IBM3151, etc)
>>
>>
>> On Sun, Feb 02 2020, Nick Black wrote:
>>
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Nick Black <dankamongmen@gmail.com>
>> >
>> > * Package name    : notcurses
>> >   Version         : 1.1.4
>> >   Upstream Author : Nick Black <nickblack@linux.com>
>> > * URL             : https://nick-black.com/dankwiki/index.php/notcurses
>> > * License         : Apache-2.0
>> >   Programming Lang: C, C++, Python
>> >   Description     : Character-mode graphics and TUI library
>> >
>> >  notcurses facilitates the creation of modern TUI programs,
>> >  making full use of Unicode and 24-bit direct color. It presents
>> >  an API similar to that of Curses, and rides atop libtinfo.
>> >
>> > Work on notcurses began in November of 2019, and it has had
>> Debian-compatible
>> > infrastructure (debhelper compat level 12) from the beginning. As of
>> February
>> > 2020, it is rapidly stabilizing, and being used in several tools. I've
>> > rewritten my "growlight" disk management tool using notcurses instead of
>> > ncurses, cutting out several thousand lines of UI code along the way.
>> Nestopia
>> > is about to merge notcurses support (coming out of maintenance mode to
>> do so).
>> > I'm working on a console SDR visualization tool that will make working
>> with
>> > remote SDRs much more pleasant, and expect to release it soon.
>> >
>> > Sid/unstable debs are available (and have been available for weeks) in
>> my repo
>> > at https://www.dsscaw.com/apt (this repo is available in Wouter
>> Verhelst's
>> > extrepo tool). The Debian packaging that I currently have can be seen
>> here:
>> > https://github.com/dankamongmen/notcurses/tree/master/debian
>> >
>> > Notcurses can be regarded as a successor to ncurses. It provides much of
>> the
>> > functionality of that package, with major improvements IMHO regarding
>> Unicode,
>> > multithreading, and color support. 24-bit RGB with two bits of
>> transparency is
>> > the fundamental color space, and input/output are entirely based off
>> UTF8 and
>> > Unicode's Extended Grapheme Clusters. I've written many thousand lines of
>> > ncurses code in my life, and expect to write no more--notcurses will
>> entirely
>> > supplant it in my projects. ncurses is a venerable, robust library, with
>> a
>> > fantastic maintainer in Thomas E. Dickey, but it's fundamentally bound to
>> > X/OSI. It's time to move past 90s-era TUI APIs.
>> >
>> > As for maintaining the package, I've written 90%+ of the code in
>> notcurses, and
>> > intend to maintain it for the long haul. I'm actively committed to
>> maintaining
>> > the Debian/Ubuntu packaging, and indeed hope to use it as a springboard
>> towards
>> > Debian Developer status.
>> >
>> > notcurses has been included in Arch's AUR since its 0.4.0 release in
>> November
>> > 2019.
>>
>>


Reply to: