This represents an essentially complete rewrite of ncvisual and associated code. It had two major goals:
Improve the ncvisual API based off lessons learned, pursuant to the upcoming API freeze. In particular, I wanted to:
decouple ncvisuals from ncplanes. It should be possible to render a ncvisual to multiple planes, with different scaling each time. It should be possible to create an ncvisual without a plane, etc.
normalize the various ways of constructing an ncvisual -- file, memory, plane, etc.
Support multiple blitters, from 7-bit ASCII to Sixel. This required writing the blitters in several cases, and they're not yet in their final implementations (but the API is fine)
I have not yet unified Plots and Visuals, and might not, given that the Plot code works fine. We could at this point implement Plots in terms of Visuals, though -- the blitter backend range has been unified. Sixel is not yet implemented, though it is listed.
There is a new POC tool, blitter. It renders its arguments using all possible blitter+scaling combinations. Another new POC, resize, displays its argument, then resizes it to the screen size and displays that, explicitly making use of ncvisual_resize() rather than a scaling parameter to ncvisual_render().
This also eliminates some memory leaks and bugs we were seeing in trunk, and brings in Sixel scaffolding.
The C++ wrapper will also need patching back up; I cut most of it down while wrestling with this crap, urk.
Closes#638, #562, and #622.
This is to make it possible, in the future, to create multiple instances
of `NotCurses` for multiple terminals. The first instance of
`NotCurses` becomes the default one, so that any instances of other
classes that aren't explicitly created with a pointer to another
`NotCurses` instance still work as expected.
Note that currently trying to call `notcurses_init` twice results in the
following error for me:
0x55555559bfc0 is already registered for signals
Couldn't drop signals: 0x55555559bfc0 != 0x5555555b6720
terminate called after throwing an instance of 'ncpp::init_error*'
Program received signal SIGABRT, Aborted.
The error is signalled by `setup_signals` and the pointer shown in the
message points to the first `struct notcurses` instance created.
Fixes: https://github.com/dankamongmen/notcurses/issues/616
SIGSEGV was caused by an invalid cast.
Short explanation: PEBKAC
Long explanation: `Selector.hh`, `Plot.hh` and `MultiSelector.hh` did
not include `Plane.hh`, they merely declared `class Plane;` because
inclusion of `Plane.hh` would cause circular dependencies to appear and
the compiler would be unhappy. On top of that, yours truly wrenched the
compiler's hands and caused it to believe that a pointer to `Plane` is
really a pointer to `ncplane*` which was quite a silly thing to do as
the compiler, not having included `Plane.hh` and thus not knowing full
definition of the type, wasn't able to look up the type cast operator in
`Plane`.
Don't abuse `reinterpret_cast`, kids!
Added:
* class FDPlane (`ncfdplane*`)
* class Subproc (`ncsubproc*`)
* NotCurses: get_inputready_fd (`notcurses_inputready_fd`)
* Plane: qrcode (`ncplane_qrcode`)
* class PlotBase: templated base class for Plot variations
* class PlotU: `uint64_t` instantiation of PlotBase (aliased to previous
`Plot` class for source compatibility), `ncuplot*`
* class PlotD: `double` instantiation of PlotBase, `ncdplot*`
ncvisual_destroy() already calls ncplane_destroy() when
appropriate. There's never a need for the C++ wrappers
to explicitly free the Visual's underlying Plane. With
this change, valgrind no longer complains upon exiting
notcurses-view(1).
As it turns out, we can't portably load the initial terminal contents
(there are some hacks of various EXTREME nature, but none of them are
worth it for the rather limited benefit). The O(1)-time damage
inference requires knowledge of what was previously present to
inibit unnecessary draws. We would then need some special cell value
indicating "not yet written to" to distinguish a purposeful null
cell from an initial cell. Again, we could do this, but for what value?
Finally, the idea of clearing new area on SIGWINCH was always flawed,
as we can't do that from a signal handler.
With the advent of direct mode #77, the reason for this largely goes
away in any case.
