add missing capabilities functions to direct mode

[joseluis]

Right now it's not possible to check the same capabilities in direct mode as in full mode. The missing ones in direct mode are:

• ncdirect_canbraille()
• ncdirect_cansextant()
• ncdirect_canquadrant()
• ncdirect_canhalfblock()
• ncdirect_canopen_images()
• ncdirect_canopen_videos()
• ncdirect_cantruecolor()
• ncdirect_canfade()
• ncdirect_canchangecolor()

[dankamongmen]

i hesitated to add all of these because i didn't like the idea of symbol explosion. maybe i'll add a ncdirect_get_tinfo() primarily for internal use (but it would need be exposed), and then implement all of these as inline functions. we'd then express each of these as a tinfo_can*() function (these would also need be exported, yuck), and reimplement the notcurses_can*() functions atop them. we couldn't make these latter inline just yet (ABI breakage), but we could for ABI3.

or maybe i just shouldn't care about the number of exported symbols.

[joseluis]

Part of my motivation for asking this is that I'm currently wrapping all the capabilities in a single Capabilities struct (in notcurses-rs), and the idea was to be able to get the same struct either from Notcurses or NcDirect.

or maybe i just shouldn't care about the number of exported symbols.

I surrendered long ago to the humongous number of functions of the C API, lol... My goal in the higher-level rust bindings is to provide a minimal and versatile public API that hides most of that.

[dankamongmen]

Part of my motivation for asking this is that I'm currently wrapping all the capabilities in a single Capabilities struct (in notcurses-rs), and the idea was to be able to get the same struct either from Notcurses or NcDirect.

that isn't a bad idea at all. i think i might introduce exactly that for ncdirect. thanks for the suggestion!

I surrendered long ago to the humongous number of functions of the C API, lol...

[schwarzgerat](0) $ wc -l src/dsscaw/notcurses/debian/libnotcurses-core2.symbols 
386 src/dsscaw/notcurses/debian/libnotcurses-core2.symbols
[schwarzgerat](0) $ 

damn! i had no idea it had grown that large.

[joseluis]

that isn't a bad idea at all. i think i might introduce exactly that for ncdirect. thanks for the suggestion!

If you do that, then go all the way and change how's done in the notcurses context too. After all, it's usually a single time operation, and having all of them updated together in a single place is handy.

And you can remove a lot of functions in a single shot XD

[dankamongmen]

If you do that, then go all the way and change how's done in the notcurses context too. After all, it's usually a single time operation, and having all of them updated together in a single place is handy.

of course, but i can't do anything like that until ABI3. removing a symbol is an ABI break, even when replaced with an inline (already-compiled programs will fail to link). i would mark them deprecated, and then kill them off for 3.0.0.

[dankamongmen]

so i suggest the following three functions to replace all existing capability functions:

typedef struct {
 // blah blah blah
} nccapabilites;
struct nccapabilities* notcurses_capabilities(const struct notcurses*);
struct nccapabilities* ncdirect_capabilities(const struct ncdirect*);
void nccapabilities_destroy(struct nccapabilities*);

we need to originate the object inside the library boundary, or else we can't freely add new fields in the future (since older clients would pass too small an object). we could have a nccapabilities_create(void), but why bother? we don't need reuse this object, so there's no reason to accept a preexisting one. so just always heap-allocate and return, but make the definition public so we don't need to have two dozen functions accessing fields.

c++ can wrap this with an RAII using nccapabilites_destroy() as a custom deallocator, and i assume you can do something with rust to hide the dealloc. c users eat shit, as usual.

[dankamongmen]

hrmmmmmmmmmmmmmmmmmmmm.

no sir, i don't like it. let's instead do:

typedef struct {
} nccapabilites;
const struct nccapabilites* notcurses_...
const struct nccapabilites* ncdirect_...

and we will have a single nccapabilites struct inside the notcurses and ncdirect objects. we'll hand back a const reference. user is responsible for not using past the lifetime of the parent object. eliminates allocation and population cost, plus need to call destructor, at the cost of making possible unsafe late references. well, don't do that.

[dankamongmen]

i've started this work in dankamongmen/direct-capabilities

[dankamongmen]

ncdirect_canopen_image() already exists, btw

[dankamongmen]

putting up a PR momentarily