* Reimplement the widget zoo demo. The previous PoC
was a multithreaded monster with behavior dependent
on screen geometry. Replace it with a single thread state
machine. Closes#936.
* Support titles for ncplot. Adds title to the ncplot_options
struct, which may be NULL. Closes#941 .
* Properly color ncplot according to maxchannels and
minchannels. Closes#940
* Add tools/function-table.sh script for generating public API list.
When we don't have a pidfd available on which to poll(2) (this
is true of Linux pre-5.3, and FreeBSD), we can't rely on a
child death breaking our poll loop. Instead, in this case launch
a second thread, which just sits on a blocking waitpid(2). If
it gets an exit, it calls the completion callback, triggering
the teardown. Closes#728, and ought lets us run the test suite
on FreeBSD.
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 commit introduces the same shared library versioning scheme as used
by the SDL library. The advantage is that different versions of
notcurses can be installed alongside each other (which is not an
unlikely scenario, as SDL itself certifies) and that, if the versioning
protocol is followed, any change to ABI will produce a DSO whose name
will not break any applications linked against any previous version.
* fedora: dep on OpenImageIO, and use it
* fedora: dep on libqrcodegen-devel
* fedora: BuildRequires OpenEXR-devel
* tight check on USE_MULTIMEDIA
* CMake: enable notcurses-view for ffmpeg OR oiio
* notcurses-view: don't reach into libav
* oiio: ncvisual_render() #453
* oiio: need our own properly-offset ncvisual_plane()
* `visual` poc: accept optional command line argument
* oiio: work for 3-channel images #453
* oiio: destroy ncvisual's plane if we own it #453
* notcurses_visual.3: s/FFmpeg/multimedia/g
Split out the python demo and wrappers into their own package,
python3-notcurses. Make an archful dependency for the devel
package to the main library. Comment up test disabling.
More or less. Here's a list of things I changed:
* Single line BuildRequires which is more of a convention than a
requirement.
* Drop make from BuildRequires. That's one we do actually provide.
* Use pkgconfig(ncurses) to get the ncurses-devel BuildRequires.
* Add a 'devel' subject and move development files there.
* Add a 'static' package for the .a libraries which is common
for other packages that provide static libraries.
* Add doc files using %doc
* -DUSE_TEST=off -> -DUSE_TESTS=off
* Use %autosetup in %setup which covers adding patches in the future
for downstream packaging.
* Use path macros in %files
* Correct the date format in the %changelog entry
* Use the 1.2.6 release as an example
Things that could use more consideration:
* The release artifacts don't match what GitHub provides. Their
automated download link gives you notcurses-1.2.6.tar.gz but the URL
calls it v1.2.6.tar.gz.
* There is no signature file uploaded.
* notcurses-tester and notcurses-viewer do not build.
* Should the demo programs go in the main package or devel. I felt
devel was more appropriate.
* Should the packaging be further refined to split out the C++ runtime
and static libraries to separate subpackages?
I did some local test runs using mock. I ran the SRPM through rpmlint
which would happen when the package is submitted for inclusion.
For the download archive and signature, I create new release posts on
my github projects and create a separate tarball and sign that and
upload them there. It is separate from the GitHub automated
make-me-a-tarball download link. That might be what you're planning
on doing.
