split out direct mode?
dankamongmen opened this issue · 9 comments
I've always hated Direct Mode, but it was necessary to do a certain kind of tool. With the advent of #1823, there's a path to getting away from it, and having a pure notcurses_ world. That would be the end of a ton of code duplication with minor changes, and greatly simplify the library. I think that's a definite long-term goal.
I haven't wanted to split out direct mode from libnotcurses-core yet, because it does share a good bit of code with the latter. but it definitely bloats up the library.
If the #1823 solution proves sufficiently flexible and robust, I imagine we'd want to split Direct Mode out, and make it its own library (for backwards compatibility with existing users). at that point we'd probably stop working on it.
This is post-3.0 material, but putting it down just to let people know long-term thinking.
Thank you, I guess wont have add it to the hi-lvl rust wrappers then. But I'll wait to remove it from libnotcurses-sys until this is done.
yeah this is months down the road at the earliest. please don't remove anything.
yeah this is months down the road at the earliest. please don't remove anything.
maybe I'll just remove ncdirect_hline_interp & ncdirect_vline_interp and get them out of the way for #1339.
i mean, seriously, i'd really rather you not kill functionality if possible. what's the problem with those two? that they're using const char*, and char has different signedness on different machines? doesn't that also run into a problem lots of other places?
yeah ok np, I'll fix them too.
so i don't see this happening for ABI3, almost certainly (though scrolling rendered mode may well be complete by then, and indeed i expect it to). but i think ABI4 will see it cast off. in that case, i think we ought prepare for a future divergence in ABI3 -- we ought split this off into notcurses-direct.so so that people start linking to that. that way, we can optionally build it as a compatibility module in ABI4.
i am feeling more and more confident that cli mode will replace direct mode.
i've now converted notcurses-demo, ncneofetch, and notcurses-info all to use CLI mode. we are almost certainly going to deprecate direct mode sooner rather than later.
so i'm thinking maybe we never truly deprecate direct mode -- after all, "styling your printfs" is still going to fundamentally be necessary sometimes.
the goal instead should be to eliminate code duplication such that direct mode is an insignificant maintenance / size burden.
but it's a definite conceptual cost for anyone approaching Notcurses.
if we broke out notcurses-direct, we'd need either duplicate all the shared code between notcurses-core and notcurses-direct, or break out a new internal library, call it notcurses-internal, and link them both against it. inline functions mean many would be duplicated even in this tedious case. with that said, there's not too terribly much code that would be duplicated. given the annoyance of getting a fourth library package through debian package review, let's bypass that.
libnotcurses-core would no longer link against libreadline.
we would support a new option USE_TARGETS with values notcurses, direct, and all, defaulting to all.
there's also the question of multimedia. we would have to introduce a distinct direct-core and direct. ughhhhhhhhhhh, i hadn't realized that before. alright. let's just leave it all as one piece, and weakly deprecate direct mode -- mark that it's no longer actively developed, and CLI mode ought be used in new code. try to reduce it. etc.