mirror of
https://github.com/Aigor44/ncursesw-morphos.git
synced 2024-12-27 07:49:06 +08:00
180 lines
9.0 KiB
HTML
180 lines
9.0 KiB
HTML
|
<!DOCTYPE HTML
|
||
|
|
PUBLIC "-//IETF//DTD HTML 3.0//EN">
|
||
|
|
<HTML>
|
||
|
|
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>Ada95 Binding for ncurses</Title>
|
||
|
|
</HEAD>
|
||
|
|
<BODY BGCOLOR="#99ccbb" TEXT="#000000" LINK="#4060b0" VLINK="#000080" ALINK="#ff4040">
|
||
|
|
<H1>Ada95 Binding for ncurses</H1>
|
||
|
|
The ncurses Ada95 binding is © 1996 by
|
||
|
|
<A HREF="mailto:Juergen.Pfeifer@T-Online.de">Jürgen Pfeifer</A>.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Permission is hereby granted to reproduce and distribute this
|
||
|
|
binding by any means and for any fee, whether alone or as part
|
||
|
|
of a larger distribution, in source or in binary form, PROVIDED
|
||
|
|
this notice is included with any such distribution, and is not
|
||
|
|
removed from any of its header files. Mention of ncurses and the
|
||
|
|
author of this binding in any applications linked with it is
|
||
|
|
highly appreciated.<BR>
|
||
|
|
|
||
|
|
This binding comes AS IS with no warranty, implied or expressed.
|
||
|
|
<P>
|
||
|
|
<HR SIZE=3 NOSHADE>
|
||
|
|
<H2>General Remarks</H2>
|
||
|
|
<UL>
|
||
|
|
<LI>This document describes Version 00.92.00 of the binding.</LI>
|
||
|
|
<LI>The functionality is modelled to be compatible with the ncurses
|
||
|
|
package, a clone of the SVr4 curses model.<BR>
|
||
|
|
I did the development on an Intel box running
|
||
|
|
<A HREF="http://www.linux.org">Linux</A> 1.3.x and 2.0,
|
||
|
|
ncurses-1.9.9e and the
|
||
|
|
<A HREF="http://www.gnat.com">GNU Ada Translator</A>
|
||
|
|
gnat-3.05. For any older versions of ncurses and gnat
|
||
|
|
it will not work.</LI>
|
||
|
|
<LI>You must have the m4 macroprocessor to build this package.
|
||
|
|
If you don't have this program, you can get the FSF version
|
||
|
|
<A HREF="ftp://prep.ai.mit.edu/pub/gnu/">here</A>.</LI>
|
||
|
|
<LI>Ada programs are supposed to be readable. One of my
|
||
|
|
favourite methods to make code readable is to use expressive
|
||
|
|
names for the identifiers. You can find a list of a mapping
|
||
|
|
of the cryptic curses names to the Ada names in this <A HREF="table.html">table</A>.</LI>
|
||
|
|
<LI>This is not a typical one-2-one interface mapping. It is
|
||
|
|
close to one-2-one on the functional level. Each (n)curses function
|
||
|
|
has it's counterpart with a more or less similar formal parameter list
|
||
|
|
in the binding. It is not one-2-one with respect to the datatypes.
|
||
|
|
I tried to make records out of the flat chtype and similar structures,
|
||
|
|
so you don't have to do bit operations to mark an attributed character
|
||
|
|
as bold. Just make the boolean member <STRONG>bold</STRONG> of the record
|
||
|
|
true. The binding also hides the structures like WINDOW, PANEL, MENU, FORM
|
||
|
|
etc. ! It's a pure functional API.</LI>
|
||
|
|
<LI>I try to do as much error checking as possible and feasible
|
||
|
|
in the binding. I will raise an Ada exception when something
|
||
|
|
went wrong in the low-level curses. This has the effect that - at least
|
||
|
|
first time in my life - (n)curses programs have now a very rigid error
|
||
|
|
checking, but - thanks to Ada - you don't have to code the orgiastic
|
||
|
|
error checking style of C.</LI>
|
||
|
|
<LI>Support for wide characters is currently not in the binding, as it
|
||
|
|
is not really in ncurses at this point in time.</LI>
|
||
|
|
</UL>
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<H2>Limitations</H2>
|
||
|
|
<UL>
|
||
|
|
<LI>I provide no SCREEN datatype and functions to set a new screen.
|
||
|
|
If you need this (mostly for debugging I guess), write a small
|
||
|
|
C routine doing all this and import it into your Ada program.</LI>
|
||
|
|
<LI>I provide no functions to switch on/off curses tracing options.
|
||
|
|
Same suggestion as above.</LI>
|
||
|
|
<LI>Although Ada95 is an OO Language, this binding doesn't provide
|
||
|
|
an OO abstraction of the (n)curses functionality. As mentioned above
|
||
|
|
it's a thin binding for the (n)curses functions. But without any
|
||
|
|
doubt it would be nice to build on top of this an OO abstraction
|
||
|
|
of (n)curses functionality.</LI>
|
||
|
|
<LI>If you use the user-pointer mechanism for most of the ncurses
|
||
|
|
structures in a mixed language environemt, i.e. Ada95 and C routines
|
||
|
|
operate on the same objects, care must be taken because the Ada
|
||
|
|
binding itself uses the user pointer mechanism for it's own purposes.
|
||
|
|
See the corresponding <A HREF="#userpointer">section</A> in implementention
|
||
|
|
details.</LI>
|
||
|
|
<LI>I currently do not support the link_fieldtype functionality of the
|
||
|
|
forms subsystem.</LI>
|
||
|
|
<LI>The *_IO packages are currently output only.</LI>
|
||
|
|
</UL>
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Hierarchy of packages</H2>
|
||
|
|
<UL>
|
||
|
|
<LI><A HREF="terminal_interface_s.html">Terminal_Interface</A>
|
||
|
|
<UL><LI><A HREF="terminal_interface-curses_s.html">Curses</A>
|
||
|
|
<UL><LI><A HREF="terminal_interface-curses-mouse_s.html">Mouse</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-panels_s.html">Panels</A>
|
||
|
|
<UL><LI><A HREF="terminal_interface-curses-panels-user_data_s.html">User_Data</A>
|
||
|
|
</UL>
|
||
|
|
<LI><A HREF="terminal_interface-curses-menus_s.html">Menus</A>
|
||
|
|
<UL><LI><A HREF="terminal_interface-curses-menus-menu_user_data_s.html">Menu_User_Data</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-menus-item_user_data_s.html">Item_User_Data</A>
|
||
|
|
</UL>
|
||
|
|
<LI><A HREF="terminal_interface-curses-forms_s.html">Forms</A>
|
||
|
|
<UL><LI><A HREF="terminal_interface-curses-forms-form_user_data_s.html">Form_User_Data</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-forms-field_user_data_s.html">Field_User_Data</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-forms-field_types_s.html">Field_Types</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-forms-choice_field_types_s.html">Choice_Field_Types</A>
|
||
|
|
</UL>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io_s.html">Text_IO</A>
|
||
|
|
<UL><LI><A HREF="terminal_interface-curses-text_io-integer_io_s.html">Integer_IO</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io-float_io_s.html">Float_IO</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io-fixed_io_s.html">Fixed_IO</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io-decimal_io_s.html">Decimal_IO</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io-modular_io_s.html">Modular_IO</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io-enumeration_io_s.html">Enumeration_IO</A>
|
||
|
|
<LI><A HREF="terminal_interface-curses-text_io-complex_io_s.html">Complex_IO</A>
|
||
|
|
</UL>
|
||
|
|
</UL>
|
||
|
|
</UL>
|
||
|
|
</UL>
|
||
|
|
<H2>Implementation Details</H2>
|
||
|
|
<H4>Behind the abstraction</H4>
|
||
|
|
All the new types like <STRONG>Window</STRONG>, <STRONG>Panel</STRONG>,
|
||
|
|
<STRONG>Menu</STRONG>, <STRONG>Form</STRONG> etc. are just
|
||
|
|
opaque representations of the pointers to the corresponding
|
||
|
|
low level (n)curses structures like
|
||
|
|
<STRONG>WINDOW *</STRONG>, <STRONG>PANEL *</STRONG>,
|
||
|
|
<STRONG>MENU *</STRONG> or <STRONG>FORM *</STRONG>.
|
||
|
|
So you can safely pass them to C routines that expect a pointer
|
||
|
|
to one of those structures.
|
||
|
|
<H4>Item and Field Arrays</H4>
|
||
|
|
In C you have to pass the item and field arrays to define menus or forms
|
||
|
|
terminated by a null item or null field. This is not necessary in this
|
||
|
|
binding. The binding routines will construct from an Ada95 style array
|
||
|
|
of Item or Field objects internally the properly terminated array of
|
||
|
|
C structure pointers. See the examples for more details.
|
||
|
|
<H4>Extended ripoffline() usage</H4>
|
||
|
|
The official documentation of (n)curses says, that the line parameter
|
||
|
|
determines only whether or not exactly <STRONG>one</STRONG> line is
|
||
|
|
stolen from the top or bottom of the screen. So essentially only the
|
||
|
|
sign of the parameter is evaluated. ncurses has internally implemented
|
||
|
|
it in a way, that uses the line parameter also to control the amount of
|
||
|
|
lines to steal. This mechanism is used in the <STRONG>Rip_Off_Lines</STRONG>
|
||
|
|
routine of the binding.
|
||
|
|
<A NAME="userpointer">
|
||
|
|
<H4>User Pointer mechanism</H4>
|
||
|
|
TBD
|
||
|
|
<H4>How user defined field types work</H4>
|
||
|
|
TBD
|
||
|
|
<H4>Enumeration fields handling</H4>
|
||
|
|
The (n)curses documentation says, that the String arrays to be passed to
|
||
|
|
an TYPE_ENUM fieldtype must not be automatic variables. This is not true
|
||
|
|
in this binding, because it is internally arranged to safely copy these
|
||
|
|
values.
|
||
|
|
<A NAME="compiler">
|
||
|
|
<H4>Using other Ada compilers</H4>
|
||
|
|
This should basically not be a problem, but you have to replace a code
|
||
|
|
sequence in package
|
||
|
|
<A HREF="terminal_interface-curses-forms_s.html">Terminal_Interface.Curses.Forms</A>
|
||
|
|
that uses a hashing package supplied with the GNAT runtime, which is not part
|
||
|
|
of the Standard Ada runtimes. This should not be too hard. I intend to remove
|
||
|
|
this dependency in the future.
|
||
|
|
<H4>Port to other curses implementations</H4>
|
||
|
|
Basically it should not be too hard to make all this run on a regular SVr4
|
||
|
|
implementation of curses. The problems are probably these:<BR>
|
||
|
|
<UL>
|
||
|
|
<LI>ncurses has some additional features which are presented in this binding. You
|
||
|
|
have two choices to deal with this:
|
||
|
|
<UL>
|
||
|
|
<LI>Emulate the feature in this binding</LI>
|
||
|
|
<LI>Raise an exception for non implemented features</LI>
|
||
|
|
</UL>
|
||
|
|
Most likely you will follow a mixed approach. Some features are easy to simulate,
|
||
|
|
others will be hard if not impossible.</LI>
|
||
|
|
<LI>For menu items, the name and descriptions are internally copied by ncurses.
|
||
|
|
So the binding doesn't care for the lifetime of the strings passed to the
|
||
|
|
construction routine for items. This assumption is not true in most other implementations
|
||
|
|
of the menu library. In this case you have to modify the binding routine
|
||
|
|
<STRONG>New_Item</STRONG> to safestore the strings.</LI>
|
||
|
|
</UL>
|
||
|
|
I'm quite sure I forgot something.<P>
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|