
/*  @(#)TODO 1.4 92/04/16
 *
 *  Popi was originally written by Gerard J. Holzmann - AT&T Bell Labs.
 *  This version is based on the code in his Prentice Hall book,
 *  "Beyond Photography - the digital darkroom," ISBN 0-13-074410-7,
 *  which is copyright (c) 1988 by Bell Telephone Laboratories, Inc.
 *
 *  Permission is given to distribute these extensions, as long as these
 *  introductory messages are not removed, and no monies are exchanged.
 *
 *  No responsibility is taken for any errors or inaccuracies inherent
 *  either to the comments or the code of this program, but if reported
 *  (see README file) then an attempt will be made to fix them.
 */

Popi TODO list.
===============

* From Eli Chiprout <uunet!mitel!chiprout@munnari.oz>
  - when popi is executing it takes over its windows completely and I am not
    able to close them or move them in any way.  I can only move another
    window on top of them.  However, when I move the window away, the screen
    is not refreshed for the popi windows (if it is still running a job). It
    would be nice to be able to type a complicated command and let popi run
    with it, close the window and open it when the processing is over.

  - when I open popi, I usually type "popi &".  However, this seems to
    remove any local echo of typed popi commands.  I have to open it
    without putting it in the background.  I noticed that dbxtool in the
    Sun environment has the same problem.

* Handling of image files with extensions (eg: dmr.oil), needs to be
  included.

* The following problem exists with the NeWS version:
  - The soft cursor is not being correctly positioned in the dialog box.

  [Note that this is against an old version of NeWS; popi doesn't work at all
   with the latest versions of OpenWindows. One day Sun will stop changing the
   NeWS protocol, and this can really be fixed up]

* The following problems exist with the XView version:
  - the cursors are not correctly changing.

  - the position of the popi canvas needs to be relative (below) the
    tty window.

* From Rich Morin <cfcl!rdm@apple.com>
  - Trig table calculation is *really* slow.

  - It doesn't use the right color map unless the cursor is in the
    image window.  Could it also use the right one when the mouse is
    in the text window?

  -  :lo xxx       produces 2-line error message, but no prompt.
                   Return needed before prompt appears

  -  ^Z            kills popi; should just put it to sleep

  -  popi -\?      pretty awkward way to get help
                   error checking is needed for bogus parameters
                   should probably convert to getopt...

* From Russ Nelson <nelson@sun.soe.clarkson.edu>
  - It would be nice if Makefile.dist was automatically configurable. To wit,
    the equates that need to be commented-in should be done automatically.
    It can be done by prefixing each equate with a #BSD or #TURBOC or #AMIGA,
    etc., and running a command like the following:

        sed s/^#BSD// <Makefile.dist >Makefile

        sed s/^#TURBOC// <Makefile.dist >Makefile

    This also makes the copy from Makefile.dist to Makefile. I can supply you
    with a small work-alike that will just do sed's s command.

  - A way to make the prun() inner loop run faster is to remove the test of
    "CurrParse != ParseEnd".  Instead, create a new opcode called "exit",
    and stuff it at ParseEnd.

    Of course, if you do any kind of transcendental calculations, they totally
    swamp the time taken by the loop operation.  But my suggested changes
    should speed up transformations with simple calculations...

* Ability to use multiple machines via a remote procedural call
  mechanism would speed the program up considerably.

* From Rich Morin <cfcl!rdm@apple.com>
  Various ideas:
  - don't require quoting of file names. There is a problem here: the parser
    doesn't like extensions, etc. in standard names.

  - -d[mns] - display modes (merged, none, separate).

  - batch mode support.

  - color as third parameter (extend syntax to treat color planes separately).

  - default x(r), y(a), and c values (eg, new[,2]=old[,4]).

  - #system <cmd> [arg...]

* Add in online help.

* Parametrise some of the special functions, such as genepson.

* Better dithering for epson driver.

* Variables and comma operator, for expression optimisation
  eg new[x,y] = (t = old[x,y] / 2) < Z/10 ? t/2 : t
  or whatever.

* The run time interpreter could be self modifying code. That
  is, instead of compiling pseudo-operations onto the parse
  stack, generate real machine code to do the same thing; then
  execute this inside run().

* Catch signals and longjmp() to prompt. Need to call driver-
  specific signal handler to clean up in the middle of an image.

* Optimise initial new[x,y] to @

* In I/O, change isalpha() test to allow digits and '_'.

* Do proper optimisation, including precalculation of vectors in run().

* Convert NeWS driver to use the tNt toolkit and get working with the latest
  versions of OpenWindows.

* Grayscale "colour" MGR version.

* Various PC problems and suggested enhancements:

  - should use appropriate pointer typedefs (using nonstandard memory
    reference keywords if available) for the image data.

  - when popi is compiled with any but the small memory model, it hangs,
    even on a small image that works with the small model version.

  - need to add support for remaining standard board types. Also need to
    do compiler-independant adapter detection.

  - allow the PC driver to (optionally) be compiled with graphics.c.

* Need to get command-line option processing right, allowing it to
  be passed to disp_init, but still giving an error message for
  unrecognised options.

* If the image read in is in old format and compressed, then the rewind
  command will fail because you can't seek on the pipe from zcat. Old
  format images cannot be compressed anymore.

* Need to check that color works with all known popi versions.

* Need to check that 24bit support works with all known versions.

* From Thomas M. Breuel <tmb@ai.mit.edu>
  It would also be nice if it were possible to display multiple images.

* The help message mentions two specials, :create and :run which haven't
  been implemented yet.

* From Rob Beukers <rob@dutetvd.ET.TUDelft.NL>
  Suggestion: Command :shift (the same as new[x,y]=old[x,y])

* Compressing the grayscale colormap doesn't quite work correctly when the
  image has less than 256 colors.

* The XView driver is currently broken. It hangs when trying to allocate
  the first color from the default colormap.

* From Dave Spensley <davesp@ecs.comm.mot.com>
  When a picture filename is passed on the command line, whose height is 480,
  the height of the displayed image seems to be 512 (a small area of white
  appears between the bottom of the image and the bottom of the frame).  The
  width adjusts okay, though.

* From Eric Haines <erich@eye.com>
  The X11 version of popi doesn't display correctly on 24/32 bit screens.

* Optimise parsed expressions such as (Z+1), like the previous version of the
  parser.

* From Stephan Wasserroth <wasserroth@fokus.berlin.gmd.dbp.de>
  Build a real nice NeXT application (similar to Mathematica - notebooks et al).
  The code becomes a little inconsistent (due to lots of changes :-). A general
  restructuring/rewrite would be helpful - lots of small bugs are lurking
  anywhere (i.e. checking that the given image really exists).
  A better compiler with optimizer is needed. Compiling to machine code would
  things speed up dramatically, especially color operations.
  A macro facility and script file processing would be nice.

* All graphics drivers (apart from next.m) need to be fixed up to use the
  new len parameter supplied in the disp_imgstart() routine. See v3.2,
  patchlevel #2 notes in the CHANGES file for more details.
