now. The main goal here is to allow A_BOLD to select *either* high
intensity color (the old behavior) *or* a genuine bold font (the new
option for SDL-TTF and X11), but not both at once; and also to
facilitate similar choice with A_BLINK in the future. (High-intensity
color can still be combined with bold fonts by directly selecting one of
the 8-15 colors.) A_ITALIC is also half-covered, but since A_INVIS is
kind of useless, I've omitted PDC_set_italic(). To Do: Test everywhere;
more docs.
compatibility with old BSD curses. Also eliminated the "MONO, COLOR" and
size info from longname(), partly because it's now initialized only at
startup (ignoring resizing), and partly because it was useless anyway.
"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.
problem: They use wint_t rather than wchar_t. wchar_t is defined in C89,
but wint_t is only in Addendum 1, from '95. I could typedef wint_t
myself, but that seems like a bad idea for many reasons. So: Create a
new ifdef, USE_WIDE, and define it only for Win32 and X. That also saves
the overhead in DOS and OS/2, but it means that the base build reqs for
Win32 and X are even more recent. I doubt this is the final solution.
really need the card info? Everything's VGA now; it's not accurate in an
OS/2 window; it's never been available under what are now the main
platforms; and it's the kind of thing that curses is supposed to shield
you from anyway. Does anyone _use_ this info?
UNICODE define (though they're unlikely to do anything useful without
it). However, they're still dependent on CHTYPE_LONG, since without it,
A_CHARTEXT is only 8 bits. To Do: Hmm...
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.
"pdcurses"; longname() returns "PDCurses for [platform] [adapter]
[COLOR/MONO]-YxX" (adapter is only defined for DOS and OS/2). This is
the first time these functions return _anything_ in Win32.
