notcurses ui backend

[dankamongmen]

The other day, I posted about Notcurses 2.3.0 to r/linux, and u/sablal (who i think is @jarun) mentioned a potential nnn rewrite. I wanted to open up communication channels and offer whatever help I could as author of that library. nnn moving to Notcurses would get me some great exposure and exercise paths of the library that might not be well-traversed by my applications, while I think a move to Notcurses would very much help along some of nnn's visual effects (which are already pretty impressive, and pushing the boundaries imho of what NCURSES can achieve).

Notcurses is distributed in a number of Linux distributions, FreeBSD, and Dragonfly BSD, but I know nnn needs support at least OSX and Windows beyond that. I'm an MSFT employee, and am about to start looking into getting it built on Windows (I was thinking native dlls, rather than WSL/Cygwin -- we might already work within the latter). @Grendal has a PR out to get us working on OSX. I can try to get packaged on any Linux distributions we're lacking. I do actively support musl, so that's not a problem.

I've converted two of my own TUI applications from NCURSES to Notcurses, covering several thousand lines of UI code in each case. It's not too difficult, and I'm happy to help, even to the point of directly contributing code to help the effort along (if it's decided nnn wants to go down this path). I think you'll find it rationalizes a lot of peculiar decisions frozen in time by Curses. If you're pretty much using PANELs and other NCURSES objects, it's practically a 1-to-1 conversion, and you can then start using more advanced features.

Describe the solution you'd like

I'd like to see nnn achieve greater visual effect through use of Notcurses, and I'd like the testing, feedback, and positioning that would come from such a "client" application.

Describe alternatives you've considered

Relative to NCURSES (libncursesw) and netbsd-curses, Notcurses brings you:

• sane, complete unicode support built around the EGC concept
• 24bpc color and/or palette-based color
• multimedia support via ffmpeg/OIIO, plus very complete blitting support
• well-defined and performant use with multithreading
• a decent set of widgets, though admittedly not as much as CDK
• a much more robust multiplanar system

Areas where NCURSES has an advantage include: its Forms library, which has yet no Notcurses equivalent, the portability and known properties of a 50-year-old API, and better compatibility with very old (primarily hardware) terminals.

ol course, any area where Notcurses is lacking, i can improve. NCURSES is not exactly the most dynamic of libraries these days.

Additional context

If you'd prefer to do this via email, hit me at nickblack@linux.com. Feel free to delete this issue or do whatever else you'd like with it. I'm excited about the prospect of working with you!

[jarun]

Thanks for the heads-up!

Adding @KlzXS. Whenever he has the time.

[jarun]

Added a line item in the rolling ToDo list with a reference to this defect for details. Closing this thread.

[KlzXS]

Hey @dankamongmen, nice to you here!
Sorry for such a late reply I am and will be quite short on time until June.

nnn won't be replacing ncurses with notcurses. At least not yet. The plan is to port it to notcurses to see how it feels like and what it can do.

I think it would be best to start work based on the next release of nnn which I'm expecting to be around the begining of June. That way any outstanding ui updates will be finalized and we'll have a "stable" version to work with.

Now I have to ask @jarun how should we organize the work. I'm not in favor of using compile guards. It would make the code hard to read. Maybe if we used functions to abstract the printing functions, but I'm not sure if that can be done nicely due to differences between ncurses and notcurses.

Second idea that comes to mind is to introduce a new branch for notcurses. I'd say it would be ok to only update it once per release.

And third, to tie into my future plans for nnn: make it a custom patch. I will write documentation for patches so that we can showcase some good and useful user patches. This has been discussed quite some time ago.

Choose one you like the most.

Finally I should mention that I don't have any real experience with ncurses and the like. But seeing how notcurses claims to not be compatible I don't see that as an issue.

Feel free to tag me for further discussion, but don't expect a super quick answer.

[jarun]

make it a custom patch

This. And take your time. This will remain an experimental option like netbsd-curses till someone does a thorough testing.

[dankamongmen]

thanks for the lengthy reply, @KlzXS . i think a branch seems the way to go, so that it can track development on your trunk easily.

based on a survey of nnn, i think Windows and OSX support would be necessary before any kind of port is worth working on. I'm thus prioritizing that work, with the goal of having it done by the end of June, probably before 3.0.0 is released. Until we can demonstrate actual delivery on those targets, there's just not much reason for nnn to devote effort. I imagine you agree?

In the meantime, though, you might want to write code such that it's more trivially portable when the time comes. One thing I'd recommend is that you cleanly define your palette in terms of RGB values, using palette-manipulation routines from NCURSES. That way, you can trivially switch to Notcurses (or any other 8bpc RGB-based solution). Notcurses does support palette-indexed color with custom palettes, so technically a conversion to 8bpc methods wouldn't even be necessary.

Finally, I'd be happy to kick off this work for y'all, once we're at a point where a move seems likely (assuming the code lands). By that I mean bootstrapping nnn up to where it's pretty much using Notcurses, but at a proof-of-concept level -- not sloppy code, but perhaps only one instance of each similar concept actually converted.

so i'd say if you want to play around with things, feel free to make a branch and do so. i'm going to ensure Notcurses covers the set of targets you support ASAP, as there will surely be some chasing down of bugs on each. once Notcurses can be built, installed, and linked on those platforms, i'll be able to either take your branch or create my own, and do the core conversions. again, before taking this last step, it would be good to exchange some thoughts regarding the likelihood of a transition. i very much don't want to be in the business of maintaining large, unmerged nnn patchsets =].

obviously, if my code is garbage, there's no expectation that you would take it, but i try to avoid being in the habit of writing garbage. you'll be reviewing it. we can then move forward as a team in the branch, or you can take it forward on your lonesome, or whatever. i'll be available for consultation if nothing else, and i'm happy to extend the API in any way reasonably needed--indeed, part of the value to me here is that my API gets another, very different program to exercise it, and see where it's incomplete.

so that's what i can offer you. what you can do to help me in the meantime is twofold:

• i'm sure there are multiple ways and idioms to build programs on OSX/Windows. what is the idiom used by nnn? would you change it if you trivially could? what ought i ensure i do to ensure i'm easily consumable by nnn?
• if you wanted to list some capabilities you need/want, in terms of widgets or whatever, that would be great.

looking forward to hacking with y'all!

[KlzXS]

@dankamongmen We'll hold off on implementing support for notcurses for now.
I don't have time to dedicate to this now and we believe it wouldn't benefit the project much, so we're putting it as low priority.
We'll revisit the idea at a later date when someone has ample time to dedicate to it.

I'm unlocking the issue so you that you can reply if you have anything to add.

[dankamongmen]

understood. don't hesitate to reach out if the situation changes! we are. ow supporting Mac and windows, btw.

[KlzXS]

Right, I just saw that that's a thing. Wish you the best of luck with that endeavor.