Goals for the January 1992 release (!!)

[mbp]

I'm cleaning out my home directory and came across the following file
which I don't need to keep personally but I thought it would be nice
to record it here (in software.log) for posterity.  The date on the
file is Nov 25 1991.

------------------------------------------------------------------------


Goals for the January release of the OOGL/viewer monster (not in any
particular order):

I. Come up with a name for the viewer!

    Something catchy would be nice, but in the absense of such I'd
    like to propose that we start calling it "geomview" for now, until
    we come up with something better.  I'm afraid that if we stick to
    "w" or "v" or "wv" too long, they will stick permanently!
    "geomview" is at least descriptive of what it does (displays
    geoms) and where it came from (Geometry Center).

II. Compatibility with MinneView.

    A. data file formats

	My understanding is that this is not a problem --- the gprim
	formats haven't changed, right???

    B. communication

	We need to somehow support communication with external programs
	written to talk to MinneView:

	    1. Programs that use shared memory directly (trigrp,
	       dirdom, evolver, ...).

	    2. Programs that use "stuff"

		We could re-write "stuff" so that it writes its
		data to a named pipe instead of stuffing into
		shared memory.  Geomview can read from that pipe.
		Is this the best way to do this?

    C. Other???

	Are they other things we need to keep in mind?  In general,
	someone currently using MinneView should be able to start
	using geomview for the same task with a minimum of adjustment.

III. User Interface

    A. Hook up & polish Tamara's panels.

    B. Lighting editor

	Regarding the debate about whether the lighting editor should
	be internal or external: would it be possible to think of the
	entire user interface as potentially external?  Like
	Mathematica, sort of --- a computational kernal and a separate
	front-end.  We could supply a built-in, default front-end,
	which could be replaced when desired by something external ---
	perhaps a collection of specialized external front-ends (one
	for material, one for lights, one for motion, ...), any subset
	of which could actually be hooked up when needed.  The viewer
	could be compiled either with or without the built-in
	front-end. ???  This is just food for thought at the moment;
	how much work would it be to do this?

IV. Ability to save / restore viewer session

    Should be able to save various aspects of the viewer state: the
    state of the viewer itself, the geometry itself, etc.


V. Ability to save image files

    What formats ???  At least SGI format, at first.

VI. XGL viewer

VII. Documentation

    A. source-code --- clean it up, document it, and put copyright
       notices on everything in sight.

    B. other documents to write

	1. viewer man page

	2. viewer tutorial --- interactive, if possible ???  Or, our
	   philosophy could (should?) be: the we'll make the thing so
	   easy to use that no tutorial is necessary !!  Is this
	   possible???

	3. "How to write an MG device driver"

	4. "How to port the viewer to a new platform"

	5. "How to write a new gprim"



VIII.  Debugging and testing

    We need to exercise the code more --- try displaying various
    gprims, editing appearances, etc.  Track down and fix bugs bugs
    bugs!