Title:                  Proposal to improve table browser
Person responsible:     Tim Cornwell (tcornwel@nrao.edu)
Originator of proposal: Wes Young (wyoung@aoc.nrao.edu)
Exploders targeted:     aips2-glish, aips2-gbt, aips2-multibeam,
                        aips2-workers
Time table:
        Date of issue:          1997 June 10        Done
        Comments due:           1996 June 17        Done
        Revised proposal:       1996 June 20        Done
        Final comments due:     1996 June 27        Done
        Decision date:          1996 June 30        Accepted

Statement of goals:

Improve the table browser,  i.e. improve user interactions (scrolling and table
loading), add several new features (including cell editing and better
plotting), and bring the existing code up to current coding standards.


Proposed changes:
   Add the following features to the table browser:
      1. Provide options for plotting (via the plotting tool or aipsview)
         including:
          a) Plot any column vs any other column(s),
             also ranges of rows of columns,
          b) Contour plots of matrices (or display as images in aipsview),
          c) Movies of plots, array/matrices vs a selectable column.
      2. Have several view options:
          a) Allow the user to choose what columns to display/hide. If a
             column had a NODISPLAY keyword, the column would not be printed.
             The NODISPLAY option could be overridden.
          b) Allow the user to specify a TaQL to select some rows and/or
             columns and/or reorder them.
          c) Ability to produce virtual columns using column arithmetic.
             This feature will require parsing either a TaQL or a spreadsheet
             like syntax. It may also involve creating tables on the fly with
             the virtual columns.  The current table grammar is sufficient
             to do this.  Provide an additional option to make the virtual
             column persistent.
          d) Use a keyword (DISPLAY_FORMAT) to let the user specify how
             text/numbers would appear. Have a DEFAULT_DISPLAY_FORMAT keyword
             for retaining the default format.
          e) User selectable units using DISPLAY_UNITS keyword. Have a 
             DEFAULT_DISPLAY_UNITS keyword for retaining the default units.
          f) Show small arrays. The size would be user selectable.

          Note: Keywords are optional.  If no keyword is presen use a "normal"
                output format.

      3. Limited Editing capabilities
         a) Edit individual cells in the table.
         b) Edit table/column keywords.
         c) Add row(s) to table -- add a number of rows (with default entries)
            to table (cells can then be edited): enhances possibility
            of easily updating small tables (e.g. observatory positions).
         d) Read-only toggle for columns and whole tables.
      4. Allow user to specify formating of columns (I would think only simple
         primitive types could be formatted, measures would have to wait and
         then only some measures will lend themselves to reformatting).
         
   Identify the best scheme for doing the table rendering.  There are at least
   three options:  
      1. Use the current scheme of drawing on the canvas,
      2. Use entry widgets drawn on the canvas, or 
      3. Use a TK widget/glish client to render the table.
   A four option of writing a C++ (or Java)  program instead of glish script
   exists but wouldn't integrate as easily with other glish tools for display??

   Make the following implementation changes:
      1. Better caching scheme for large tables (use double buffering??),
      2. Better scrolling/windowing control,
      3. Use "closure objects" internally,
      4. Move glish code into gui-framework (standard look & feel),
      5. Use one render for arrays/tables, and
      6. Make functions available via a menu-bar (table loading, views,
         plotting features, etc.)

Expected Impact:
   The table browser would be a more useful tool for exploring/analyzing data
   in AIPS++ tables.

   The table browser code will have to be moved into the gui-framework scheme.
   Existing code that is kept will need to be turned into closure objects. 
   Identifying the best rendering scheme will require a couple of different 
   prototypes.

   Some work on for making "on-the-fly" virtual columns maybe needed (Ger
   believes everything is place to do this, it just needs to be implemented).

   Features 2 b,c and 4 would likely be implemented after the new table
   distributed object has been finished.

   Will take a about two to four weeks to accomplish.

Proposed documentation changes:
   New features will need to be documented.  A short tutorial on effective
   table browser use will need to be written.