"PDCurses Description"; various cleanup. The new policy is simply to
describe PDCurses' behavior; if anyone wants the canonical descriptions
(which these weren't, anyway), they can refer to X/Open directly.
I only kept it in 2.8, rewriting it to mention trademark, to make it
clear that PDCurses was always public domain, despite the seemingly
contradictory wording in the boilerplate, and that trademark (not
copyright) was the only basis for restricting distribution in this case.
But I don't want to be like the Mozilla Foundation.
get..x. Also added getcury() and getcurx() functions. There were
numerous problems with the macros (poor maintainability, interference
with namespaces, bloated executables, etc.), and only one supposed
advantage: performance. Testing (even on a simulated 4 MHz machine) does
not show this advantage. The function call overhead is trivial compared
to other bottlenecks. The only other reason to keep them would be
tradition... and the faint possibility that someone, somewhere is
ifdef'ing off them (the same problem that undid my attempted enums). But
in this case, I really doubt it. Note that Larsson's Pccurses didn't use
the macros; comments by Frotz suggest he added them to conform to the
standard, but they aren't required by issue 4 version 2 (while the
functions are).
implemented for X. There's some controversy whether leaveok() is really
supposed to turn off the cursor... but if it's OK to leave it anywhere,
then why not leave it off the screen? Also, with this change, turning
off leaveok() will always do curs_set(1), regardless of the previous
state of the cursor.
values could be set by idlok() and idcok(). Nor do they make sense in
the PDCurses context. The only reason to consider retaining them is
compatibility -- HPUX, Solaris and Tru64 curses all have them. But
NCurses and BSD don't; and per the standard, the WINDOW struct should be
opaque, so it shouldn't matter. idlok() and idcok(), by contrast, must
be retained, although they do nothing.
2.7 (it was commented out previously). I tried all combinations of the
supported Win32 compilers, and could not get any one to build binaries
against another's libraries, except LCC against MSVC libs (even the
reverse didn't work) -- and that didn't even involve cdecl. It's
possible this could be made to work, but clearly it will involve a lot
more than just PDC_CDECL. Meanwhile, it's... well, really ugly. So I'm
dumping it, and just advise you to build PDCurses with the same compiler
you use to build your app -- as far as I can tell, that's the only way
that's ever worked anyway.
