Hi, all, for some reason i cannot explain, i've always been fascinated by that absolutely horrible API known as "curses" (specifically, the every so slightly more modern "ncurses"). Curses is difficult to work with and has some of the worst API naming conventions one can imagine, but there's something entrancing about it, as if it was embedded in my DNA 1000 generations back. i can't help it.
AFAIK, i was the first person to write JavaScript bindings for ncurses: http://spiderape.sourceforge.net/screenshots/ and now i'm struggling with the decision of how best to go about doing something similar for the libfossil script bindings. There is one big design decision which needs to be answered, and i'm looking for input from those familiar with curses APIs: a) port the low-level API 1-to-1 (some semantics differences are needed for script-space, but nothing too weird) b) supply only a higher-level API and hide the atrocious low-level API behind it? The advantage of (A) is that one can always open up their local man pages to see how a given API works (so (A) would keep the original (cryptic) API names). Likewise, that's the main disadvantage of (B): users familiar with curses would need to learn a new API and might find a higher-level API too limiting. OTOH, the curses API (a standard, btw) is pretty ugly and difficult to use properly, which almost begs for solution (B). i'm aware of the CDK (Curses Development Kit), and CDK is a Good Thing, but i'm hesitant to wrap it because then i'm stuck with that API (which i have never used). Opinions? -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
