pc.louisiana.edu/pub/unix//Louisiana_UNIX.tar/Louisiana_UNIX/xspread3.0.zoo/doc/prog_rpt

Text File | 1994-05-01 | 8KB | 128 lines

    The project I am working on is xspread.  I am working on the
project by myself, that is, with no one else.  The program has already
been wirtten.  My task is to correct some of the bugs which continue to
dwell within the program.
    xspread is a spreadsheet program suitable to be run on X Window
terminals.  It is in the public domain, so anyone may obtain a copy of
it free of charge without violating copyright laws so long as the
copyright information is passed along with the rest of the code.
    Anyone familiar with standard spreadsheets such as Lotus 1-2-3,
Quattro Pro, or Excel will find xspread to be similar but not exactly
the same.  A Postscript manuel is found in the
/usr/proj/se/xspread/fall92 directory under the name xspread.dvi.
People wishing to use this program should first print out this document
for reference.  It is 37 pages long.
    The goal of my project, as outlined in my contract, is to enhance
and modify this program.  At the present moment, xspread is already
useable and has no major defects.  but it does  have some minor
bugs/deficiencies.  I have indentified 8 specific improvements that I
plan to add to xspread.  These were taken from the suggestions found in
the xspread/fall92/TODO file.  The 8 improvements are:

    Ability to save graph definitions upon terminating a session
    Improved user interface of graphic option selection
    Improved user friendliness of graph error function
    Remember whole path name
    Coordination between docs and toggle key functions
    Correct text appearance after inserting ' " ' into a cell
    Correct cursor movement when editing a cell
    Select ranges with mouse

    The following is my progress in achieving the above enhancements
as of 3/21/94.  Keep in mind that the entire program contains over
20,000 lines of source code.  The program is written in what appears to
be a combination of C, C++, tcl and tk.  The modules are sometimes very
large, up to 2,600 lines in some cases, making it difficult to locate
those functions that need modification.  And the object oriented
principles of encapsulation do not appear to have been adhered to with
any consistency, making even the simplest of modifications a task of
major undertaking.
    The improvement that I have done the most planning on is that of
implimenting the ability to save graph definitions upon terminating a
session.  Presently, when a user reads in a preexisting file, they must
define all graphics parameters before viewing the graph.  This is often
a bothersome hassel, becasue a user usually will want to view the same
graph again and again, yet each time they load in a file the graph
options must be redefined.
    My enhancement will allow a user to define their graphic
parameters for a certain set of data.  Upon saving the file, they will
be asked if they want to save the graph parameters.
    There are 3 ways (functions) to save a file:  put, write, and
table.  Each function saves the data in a different way.  It is my
proposal, however, to have all 3 storage methods use the same method of
storing graphic settings.  Thus, all storage functions will first make a
call to the same graph storage function.
    This function will require that all current graph definitions be
stored in a global data structure.  While global variables are often
looked down upon in software engineering, their use in this situation
seems very justified. Attempting to save graph definitions without use
of a global variable would necessitate a massive revision of the program
structure.  The program flow would become extreamly complicated.  I will
store the definitions in a structure variable called graphdef of type
Graphdef.
    If the user does not choose to save the graph definitions when
saving a file, the file contents will be written exactly as they have
been in the old version.  When the user does choose to save their
current graph definitions, the first line of the file written to will
contain a marker indicating that the next several lines are for graph
definition data.  When ever a file is read in, the first line must be
checked to see if it contains such a marker.  If it does, then a call is
made to a function which will read in the definitions.  If no graph
indication marker is present on the first line, then the spreadsheet
file is read in as usual.  It is important here to remember the first
character that was consumed in the checking for graph definitions, as
this may have been a necessary part of the file data.
    Another improvement that I have made some progress on is for user
interface of the graphic option section.  At present, the user interface
presents the same messages during different function selections, which
is both misleading and confusing.
    For example, when in the main menu, if the user selects
graph/optons/format, the following submenu appears:
    Lines    Symbols       Both        Neither
If the cursor is on Lines, a descriptive message appears underneath:
"To connect each range data point with a straight line".  When the Line
command is selected, a message appears for appproximately 1 second
saying "The graph format is lines".  To me, this sounds as if it applies
to the entire graph.  Had I choosen the graph option, there would be no
problem.  But when a user, especially a new user, chooses the A - F
options, they will be left wondering what changes are going to actually
be made.  A check will reveal that a format change for the A range only
affects the A range, but it would be more user friendly if the messages
indicate for which range the changes are being made.
    Another needed improvement in the catagory of user friendliness is
the graph error function.  Graphs of type XY are viewed with little
difficulty.  However, if I have a graph of type Line, Bar, Stack Bar or
Pie, a similar attempt to view this graph results in an error message
claiming "not enough valid x values".  Beliving this to actually be the
problem, I then went on to add more x values.  However, the same error
message reoccured upon trying to view the graph no matter how many x
values I added.  A new user would become completely lost from such an
error message.  The problem and specific sloution must be clearly stated
by the error function.  If there aren't enough valid x values, then the
user should be informed of how many more x values need to be added.  And
if the amount of valid x values isn't the problem, an entirely different
error message should appear.
    The problem of remembering the whole pathname shouldn't be too
hard to fix.  When a file is initially read in, it's name and path will
be stored in a static variable.  When saving or reading in the next
file, the static variable will be printed out as default.  This will
save the user the effort of having to type out either the pathname or
filename, unless they want to specify a change.
    Coordination between toggle key functions and their documented
actions will require furthure investigation.  As of this moment, I have
not found what is wrong with the toggle keys - they seem to be working
fine.  It is mentioned in the TODO file that some of them do not match
the docs as close as they should.
    The next two improvements, which are to achieve correct text
appearance after inserting ' " ' into a cell and correct cursor position
when editing a cell, are presently without a strategy.  It is mentioned
in the documentation that these bugs were looked into, but the source of
the error could not be found.  I too have not found the source of the
error but will keep looking.
    The last improvement I hope to make is to allow the user to select
ranges with the mouse.  I have not yet gotten this far and have no idea
of how I will get this done.  I intend on making the range selection by
mouse work similar to the other spreadsheet programs such as Lotus 1-2-
3, Quattro Pro, etc.