pcurses
directory. It has
not been integrated into the rest of the makefiles or fully debugged.
pscreen.h
,
display.h
,
attrib.h
,
keyboard.h
. The interface does not provide any windowing.
Windows are implemented in additional layers on top of pscreen. Pscreen
lets you draw on the physical screen, treating it as a 2D array of
character/attribute pairs.
The first thing to notice is that there is
a header called "curses.h". This is for a curses package that is implemented
on top of pscreen, and is also used internally by the fsp implementation
of pscreen. It is almost certainly not compatible with your
system curses. Furthermore, the "attrib.h" header has definitions for
constants like A_BOLD
that also appear in your system curses.h.
These are not the same as the constants in your system curses.h.
Perhaps it was a mistake, but the constants in attrib.h have the same names
as the constants in the standard curses.h to make implementing curses on top
of pscreen easier. This means that your code cannot use both the pscreen
interface and the standard curses interface - but there are many other
reasons why this would not work as well. For instance, they are both trying
to control the screen and keyboard. Application code should not be
including the curses.h in fsp, or the standard curses.h either. Only
the implementation code in fsp should include curses.h. (Unless you
are using the curses built on pscreen - which is not included with
the tuipeer source.)
That said, I should make it clear that you can use standard curses to implement the pscreen interface. In fact, there is a pcurses library included that does this. Keep in mind, that when you use pcurses, you do not include the system curses in any application source. Only the pcurses.c module uses the system curses. Applications will continue to use pscreen.h, display.h, and attrib.h as before. In fact, application code should be able to link with either implementation without recompiling.
The pscreen interface is based on the IBMPC extended character set. This
is the 8-bit encoding called Cp437
in Java. This character
set has lots of line drawing and plenty of European special characters.
Furthermore, it is directly implemented by most recent ascii terminals.
This makes pscreen easy to implement for IBM PC text mode and for
ascii terminals. On the other hand, if you are implementing pscreen
using curses, curses uses the old vt100 extended characters - and only
a few of them. In its next life, pscreen will probably use unicode,
with codecs for particular 8-bit character sets.