Hints for building menu-driven system ?

[chuck at mitlns.mit.edu]

-Message-Text-Follows-
In article <2697.2600b499 at esat.kuleuven.ac.be>, luci at esat.kuleuven.ac.be writes...
>For our research, we use an in-house developed library of image processing
>routines. We want to group a large set of those routines in a menu driven
>system. 
> 
>We would appreciate receiving information on ways that you might have
>considered for building such a system. We are also interested in receiving
>information on commercially available (or public domain) systems.
> 
>The following considerations apply to our situation :
> 
>- any researcher should be able to incorporate his own routines in the
>  menu system. This must be possible without changing the menu program
>  itself.
> 
>- It must be possible to use the concept on UNIX and VMS machines
>  (especially VAX, DECstations and SUNs).
> 
>- Speed is not of uttermost importance, adaptibility and ease of
>  maintenance is.
> 
>- This system is not intended to replace our traditional programming
>  environment ; it should complement it.

  Follows is a discussion of some software from the European
Cernter for high energy physics research. It you are interested
please see the CERNLIB procedures I'm also posting.

  You are in luck!  Since you are in Belgium, which I believe is a
member state of CERN at a educational institution you can get 
KUIP  Kit for a User Interface Program (or something like that)
for free.

  Kuip is written in fortran and maintained with a precompiler
so it comes with mods to run on most large popular computers. 
(not PCs) Vax's Sun's Apollos IBM Cray HP to name a few.

   KUIP takes for input a file like the following, you can have
one main one and users can have optional ones which contain their
own menus.

MENU name
COMMAND#1 name
ARGUMENTS
ARG 1 type (real integer string vector) REQUIRED/OPTIONAL Default value
   Prompt String
ARG 2....

Command Help Text

ACTION (name of subroutine to call)

COMMAND#2 ...
.
.
.
COMMAND#3
.
.
.
SUB MENU #1...


and so on.

   It supports 3 major modes of operation. Command line, ASCII menus,
and GRAPHICS menus in a style like you see in X windows enviorments.
The input mode is user selectable.

  Commands are accessed as follows

/MENU/MENU/MENU/COMMAND in command line mode. It supports command
completion, command recall and macros. A optional package gives
a F77 *interpreter*!, which is really handy in the kind of enviorment
you are talking about. You can make your subroutines callable by the
fortran interpreter as well as commands!

 The command completion works in the most general way if you have
2 commands:

  /plots/operations/convolute
  /plots/graphics/contour-plot

Typing   "con"  will give a message that the command is ambiguous and give
both possibilities.

 Typing "conv" or "/p/o/conv" or "o/conv" or "/plots/operations/convolute"
will execute the first command.

  It will take arguments from the command line or, if they are missing and 
required, prompt with the default.

  CERN is in Geneva, Switzerland and is a large high energy physics 
facility. Their software is availble free to universities in member
countries (most of europe NOT USA) or to universities which do research
at CERN. It is available to companies in MEMBER states for several
thousand swiss francs ( it was either 2k or 10K I forget). It includes all 
source code mostly in Fortran 77 though some is assembler and C.

  They have a computer bitnet address CERNLIB at CERNVM. PLEASE note CERN
does not have the dedicated staff to handle lots of distribution.
Universities should first see if someone in their physics department
already has the library before writing to CERNLIB. In general CERN
will want to deal with 1 person at a institution not 1/per department
or...

  I'm not associated with CERN, just a happy user so I can't distribute
this software. A good way to see what KUIP can do is to look at
PAW (Physics Analysis Worstation) which comes with the CERN distribution
and is a very powerful plotting and data analysis program.

p.s. the full cern distribution requires about 50megabytes for all
the source and libraries. KUIP requires their ZEBRA memory management
package. Graphics menus require their HIGZ graphics package which is
similar to GKS with the addition of graphing primatives. HIGZ requires
another 3rd party graphics library such as GKS or X.



						Chuck Parsons
				                CHUCK at MITLNS.MIT.EDU