\renewcommand{\textfraction}{.0}
\renewcommand{\topfraction}{1.00}
\renewcommand{\bottomfraction}{1.00}
\renewcommand{\floatpagefraction}{.0}
\chapter{Introduction}

Computers can be a valuable tool in teaching science and mathematics
in universities because they offer many new features that
supplement current teaching tools.  Computers can be used to:

\begin{itemize}
\item model science and mathematical concepts so that they become
clearer to the student,

\item allow the student to browse through subjects at his or her own
pace concentrating on aspects he or she is most interested in,

\item link together of huge quantities of information
allowing the student to have the information of an entire library at
his or her finger tips,

\item cross-reference and index topics so that the student can
instantly explore topics related to the ones he or she is currently
studying, and

\item bring together information of many different forms, thereby
combining information in the form of text and pictures, with sounds
and animation.

\end{itemize}

Despite these opportunities, computers have not yet fully made their
impact in university science and math education.  The main reason for
this is that creating a computer application currently requires
writing source code at some general purpose computer language such as
C or BASIC.  This means that the average science or math professor
cannot create his or her own courseware without either learning a
large amount of computer programming or hiring a computer programmer
who is less skilled in the math and science topics the professor is
trying to teach.

Furthermore, most of the programming needed to make a science and
math education application does not involve simulating the processes
which the professor is trying to teach, but instead involves
programming such things as the user interface or file management.  
Much effort is, therefore, wasted in programming and debug source code
that has nothing to do with the things that the professor is trying to
teach.

Finally, even when courseware using general purpose programming
languages is created, the time needed to maintain and modify the
program requires much more time and effort than professors can afford.
Moreover, the applications created by different professors are
independent entities that are not linked together in anyway.  This
removes one of the main points in using a computer in the first place.

\section{The Lecture Authoring System}

The Lecture Authoring System was developed in the Spring of 1989 to
overcome these problems and allow lecturers to create their own
presentations.  It consisted of a set of graphics objects known as
``pidgets'' that could be composed into a presentation using a
graphical editor.  This system has been used on Project Athena, the
networked computer system at MIT, in the teaching of probability
(6.041) and differential equations (18.03).

The platform for LAS was the X11 Window System on a UNIX operating
system.  Since both of these systems are available on many different
types of machines, it was believed that this would make LAS easier to
port between different machines.

At first, the input and output of the Lecture Authoring System were
handled using direct low-level procedure calls to the Window System,
rather than via a toolkit.  This was done because, at the time, the
toolkits for the X11 Window System were not stable enough to use in
developing LAS.

\begin{figure}
\PSbox{/mit/cds/theses/joe/las.PS hscale=0.70 vscale=0.70}{6in}{5in}
\caption{The Lecture Authoring System}
\end{figure}

\subsection{Sucesses of LAS}

The Lecture Authoring System did prove useful for creating certain
science and mathematics applications.  A presentation using the
``pidget'' objects could be drafted in minutes.  Furthermore, slight
changes could frequently be made minutes before a class, and there was
no need to recompile applications for the different platforms
available on Athena (VAX workstations and IBM RT's).

\subsection{Limitations of LAS}
The Lecture Authoring System, however, had several limitations.  It
could only deal with one lecture at a time.  To run an application
using LAS, one started up the application with the name of the file
which described the lecture.  Once this was done, it was impossible to
load a lecture from another file without exiting the program and
starting over again.

The Lecture Authoring System was composed of two executables.  One for
showing the lecture, the other for editing it.  This proved cumbersome
because it was impossible for the lecturer to easily alternate between
viewing his or her lecture and editing it

The most important failing of LAS however was that it was too
complicated for a professor to use without help from a programmer from
the development team.  Each ``pidget'' within LAS demonstrated a
single subject, for example ordinary differential equations. Changes
to the module beyond that of positioning the object on the screen,
changing the text displayed for example, often required making changes
to the C source code, thus defeating the purpose of LAS.  In addition,
there was no easy way for one pidget to interact with another, and
adding new pidgets was complicated and laborious.

Moreover, it was difficult for even the programmers on the development
team to deal with the code for LAS.  Changes made in one portion of
the system would sometimes have unforeseen side-effects.  Modifications in the
design of the system could not be easily made due to the complexity of
the code.

Finally, in the year during which LAS was being developed there came
into existence several new tools.  The Xt Toolkit was released thus
providing a framework by that graphical interface objects such as
buttons, scrollbars, and so forth could be created.  Secondly, the
Free Software Foundation's C++ compiler, G++, became more stable
allowing programmers to use the object-oriented power of C++.

\section{The Courseware Development System} 
The Courseware Development System was conceived of as an electronic
book that professors can create or modify.  This book can be
presented as a lecture, and used later as courseware.

CDS was designed to be used by people with little experience in
computer programming.  A typical screen of CDS is shown in the figure
below.

\begin{figure}
\PSbox{/mit/cds/theses/joe/cds.PS hscale=0.70 vscale=0.70}{6in}{5in}
\caption{The Courseware Development System}
\end{figure}

Directly beneath the titlebar is displayed a Node.  A Node is
analogous to a single page or transparency.  It can be thought of as
the ``background'' or ``canvas'' onto which the professor develops his
or her lecture.  On each Node, there can be CmWidgets, which are
similar to blocks of text or figures on a printed page.  They are the
building blocks which the professor using to create his or her
lecture.  Unlike the text and figures in an ordinary book, a CmWidget
can not only display information, but they can also interact with the
user.  Examples of a CmWidget which can do this are push buttons and
scroll bars.

\section{The Navigator}
Beneath the displayed Node is the Control Box.  This is the place
where the user interacts with focus of this thesis, the Navigator.
The Navigator is the module within CDS which is responsible for
loading and saving the Nodes from a file system and organizing them
into a structure.  The goal for this thesis was to create a Navigator
which would have the minimum functionality needed to allow CDS to
operate.  This included the ability to load and save files as well as
the ability to arrange Nodes into a linear order.

Chapter 2 delves into the details of the internal structure of the
Courseware Development System.  Chapter 3 describes the internal
structure of the Navigator.  Chapter 4 proposes future developments of
the Navigator.  Appendix A is a glossary of terms.  Appendix B is a
sample session of CDS.  Appendix C illustrates the format of the lecture file
which CDS loads and saves to the filesystem.

\chapter{The Design of the Implementation of CDS}
Before examining the functioning of the Navigator, we first must
look at the design of CDS as a whole.  In designing the Courseware
Development System, we had the following goals in mind:

\begin{itemize}

\item The design must allow the average college lecturer to easily
create and modify presentations that teach topics in science,
mathematics, and engineering.  These presentations should be
interactive and should include mathematical and scientific
simulations as well as provide the ability to link related topics.

\item The editor used to create the presentations must be interactive
and graphical and provide WYSIWYG (``What you see is what you get'')
functionality.  The effort involved in using the editor must not
exceed that of overhead transparencies.  Furthermore, the user should
be able to edit and run the presentations without exiting the program.

\item The objects used by the lecturer to compose a presentation,
buttons, text blocks, plotters, for instance, should be part of some
standard toolkit, and it should be easy to incorporate into CDS other
objects in the toolkit which were not designed with CDS in mind.

\item The lecturer ought to be able to cause the objects to interact
with each other in an intuitive manner.

\item The source code for the program must be easily expandable and
maintainable.

\end{itemize}

\section{The Structure of CDS}
The first issue in designing CDS was to decide what types of objects
were to exist in CDS, and then to decide how they would be manipulated.

By using analogues in traditional educational media, it was decided
that elements of a presentation could be divided into two groups.  

One group consisted of objects such as pages or transparencies.  These
objects serve as the ``background'' or ``canvas'' which the lecturer could
work on.  These objects were implemented as C++ classes called Nodes.

The second group consisted of objects such as buttons, text, or
scrollbars.  These objects serve as display elements, which the lecturer
can use to compose an application, and through which the student can 
interact with the program.  These objects were implemented as C++ classes
called CmWidgets.  

To manipulate these objects, we designed three modules, the Navigator,
CmWidgetEditor, and Model.

\begin{itemize}

\item The Navigator is responsible to loading in the objects from disk, and for organizing
the Nodes.  It is analogous to an interactive table of contents and
outliner.  It receives both user input and instructions from the Model and
sends out a pointer to the Node to be displayed to the CmWidgetEditor, which
then displays it.

\item The CmWidgetEditor is responsible for editing and displaying
the CmWidgets for a particular Node.  It receives user input regarding the
types of CmWidgets to be displayed.  

\item The Model is responsible for interactions between CmWidgets.  It is
implemented as a Scheme interpreter whose primitives affect the functions of
both the CmWidgetEditor and CmNavigator.  It receives commands, both 
directly from the user, and in response to interactions with the CmWidgets, 
which are interpreted and which cause actions to occur within CDS.
\end{itemize}


\subsection{Nodes and CmWidgets}

There are two basic objects dealt with by CDS.  Nodes and CmWidgets.
A Node is equivalent to a single screen of information in CDS.  It
contains a title that is used by the user, and a name that is used
by CDS internally to reference the Node.  

A Node is implemented as a c++ class.  The class definition for the
Node contains the name of the node, the title of the node, the string
in the lecture file which creates the CmWidgets on the screen, and a
space for the instantiated CmWidget to appear on the screen.


\begin{figure}
\PSbox{/mit/cds/theses/joe/cds_internal.idraw hscale=0.70 vscale=0.70}{6in}
	{5in}
\caption{Structure of the Courseware Development System}
\end{figure}
A Node may contain CmWidgets.  A CmWidget is an object through with
the user can interact with CDS.  Examples of CmWidgets include
buttons, plotters, and labels.  A CmWidget is implemented as a C++
class containing an X Toolkit Widget and the resources needed to
instantiate the CmWidget.  The resources can be changed by call to a
C++ method within the class. 

\section{CDS Modules}

\section{Technical Issues}

\subsection{Object Oriented Programming}

In traditional programming, the source code is viewed as a set of
instructions to be given to the computer.  In object-oriented
programming, the program is seen to be a set of objects that interact
in a specific manner.  Each one of the objects is considered a
``black-box,'' the internal variable and procedure used by the object
are to be off-limits to objects outside of the object itself.

The advantage of this method of programming is that changes can be
made in one part of the source code with the knowledge that there will
be not unintended side-effects in other parts of the source code.

\subsection{Choice of Programming Language}

In developing CDS, there were two alternatives as to what programming
language could be used. C and C++.  On the Athena system, the only
compiler available, the Free Software Foundation's g++, was available
only for the VAX and not for the IBM RT.  In spite of this, our
experience with LAS suggested that the disadvantage in using a new
compiler would be outweighed by the the advantage in code
managibility.

\subsection{Graphical User Interface}
It was decided that a toolkit should be used for the graphical user
interface.  This decision was made for several reasons.

\begin{itemize}
\item By using a toolkit, one reduces the amount of code that needs to
be managed by the CDS development team.

\item Using a standard toolkit would reduce the time needed to introduce
new members to the project as a reference materials and documentation
would be available for the toolkit.

\item Using a standard toolkit would allow CDS to incorporate new graphics
objects developed by outside developers.

\end{itemize}

It was also decided that MOTIF ought to be adopted as the graphical
user interface.  This decision was made because to the attractiveness
of the MOTIF user interface and the availability for support from
Project Athena.

\section{Utilities For CDS}

To make development easier, two utilities were written for the
Courseware Development System, List and String.  One utility is the
List and consists of a c++ class that implements a simple linked list.
The second utility that was incorporated into CDS was the String
utility.  In conventional C, strings are implemented as a pointer a
set of characters terminated with the null character.  The problem
with this implementation is that the programmer must be concerned with
allocating and deallocating the memory that the pointer points to.
This leads to memory leaks and the possibility of segmentation faults.
Both utilities was very useful in designing the Navigator.

\section{Conclusion}
Now that we have examined the overall design of the Courseware Development
System, we can go into the details of the design of the implementation of the
Navigator.

\chapter{The Design and Implementation of the Navigator}

The goal for this term was to create a Navigator with the minimum
functionality needed to allow users to use CDS.  More specifically, I
set out to fulfill the following goals:

\begin{itemize}

\item The Navigator should be implemented as a C++ object that 
appears to the rest of CDS as a ``black-box'' which takes commands
from the user as well as from the Model, and returns to the
WidgetEditor a pointer to a Node which is to be displayed.

\item The Navigator should handle all interaction between CDS
and the filesystem.  All interaction with the file system should be
invisible to the rest of CDS.  At a minimum the Navigator should allow
the user to load and save lectures created through CDS as ASCII files.

\item The Navigator should also organize Nodes so that they
are accessible to the user.  At a minimum the Navigator should be able
to arrange the Nodes in a linear order and allow the user to flip back
and forth through the Nodes.  At the same time, it should be designed
so that future developers can easily add functions such as outlining,
indexing, and cross-referencing Nodes.

\item The Navigator should be able to create, store, and destroy Nodes.

\item The Navigator should interact with the user through a set of MOTIF
widgets as well as through menu bar.

\end{itemize}

\section{Navigator Input}

The Navigator accepts commands from two sources of input.  One is from
the user, the other is from the Model.

\section{Model Interaction}

The Navigator interacts with the rest of CDS via the Model.  As mentioned
before, the Model is a Scheme interpreter which contains primitives which
direct the behavior of CDS.  There are a set of primitives which are 
commands to the Navigator.  These primitives allow the lecturer designing a
CDS application to cause the Navigator to do something in response to user
interaction with a CmWidget.  For example, the lecturer may design his or
her application so that when the user presses a button, a Scheme expression
is sent to the Model which is interpreted and then causes the Navigator to
flip to the next page.


\section{User Interaction with the Navigator}

The user may interact directly with the Navigator in two places, the
Control Box and the Menu Bar.  The Control Box is responsible to interactions
which deal with the Node ordering aspect of the Navigator, while the Menu Bar
is mainly responsible for the file loading and saving aspect of the Navigator.

\subsection{The Control Box}

\begin{figure}
\PSbox{/mit/cds/theses/joe/cds.PS hscale=0.7 vscale=0.7}{6in}
	{5in}

\caption{User interaction with the Navigator}
\end{figure}
Much of the user's interaction with the Navigator takes place in the
control box which is located at the bottom of the CDS screen.
Currently the control box contains a list box with the name of the
screens in CDS along with buttons marked previous and next.  By
clicking in the list box, one can go to a given page.  By clicking on
the buttons, one can go to the previous page and the next page.

\subsection{Navigator Menu Options}

The Navigator can perform several different operations.  Each of these
can be controlled by the items under the ``File'' or under the
``Page'' item of the main menubar.  The ``File'' options involve
loading and saving a file to and from the file system, while the
``Page'' options involve changing the organization of the Nodes, for
example, by adding and deleting nodes.  When the item in the menubar
is selected, an Xt Callback is called which then calls the proper
method in the Navigator class.  It would be much preferable if the
callback called the method in the Navigator directory, however the
g++ compiler does not allow this.

\begin{figure}
\PSbox{/mit/cds/theses/joe/cds.PS hscale=0.7 vscale=0.7}{6in}
	{5in}
\caption{Navigator Menu Options}
\end{figure}

\subsubsection{File - New File}

The operation ``New File'' clears all of the pages associated with the
current lecture file and then displays to the user one untitled page.
The method ``NewFile'' directs the NavigatorOutliner to clear all of
its outline items and the NavigatorHeap to clear all of the nodes in
the heap.  A blank node is then created and sent to the CmWidgetEditor
to be displayed.

\subsubsection{File - Open File}
The option ``Open File'' causes the navigator to clear the current
nodes and to load in a new set of nodes from a lecture file.

\subsubsection{File - Save File}
The option ``Save File'' saves the CDS Nodes and CmWidgets under the same
filename as the file was loaded in as.  

\subsubsection{File - Save As ...}

The option ``Save As ...'' saves the CDS Nodes and CmWidgets under a
different filename as the file was loaded in as.

\subsubsection{File - Exit CDS}

This operation cause CDS to display a dialog box asking the user
whether he or she wishes to exit the application.  If the user chooses
either the ``No'' or ``Cancel'' buttons on the dialog box, CDS
continues to operate.  If ``Yes'' is selected, however, the
Navigator begins a process which results in exiting the CDS
application.

While CDS is running, it spends it's time in an event loop in the
CDS module.  This event loop receives X events and then dispatches
these events using the Xt procedure XtDispatchEvent.  CDS continues in
this loop as long as the variable in the CDS class, StopEventLoop is
set to false.  The ExitCDS method of the Navigator class sets this
variable to true and then returns.  When control is returned to the
event loop, CDS leaves the loop and the method in which the loop is
located.  Before exiting, CDS calls the destructors of all of its
modules to insure that exit processing is done.

\subsubsection{Page - Append Page}
This menu item instructs the Navigator to append a pages.  When the user
selects this menu item, a dialog box appears asking whether the user wishes
to copy the current page, or add a new blank page.  The Navigator will then
do the appropriate thing in response to the user's wishes.  Currently there
is no way on inserting a page in between two others.  This is a major
limitation which should be corrected by future developers.

\subsubsection{Page - Remove Page}
This menu item instructs the Navigator to remove a page.

\subsubsection{Page - Change Page Title}
This menu item changes the title of the current page.

\section{Navigator Output}
The output from the Navigator consists of a pointer to a Node which is
sent to the WidgetEditor via a procedure call.  The WidgetEditor takes 
this pointer, parses the descriptions of the CmWidgets inside the Node,
and then displays the proper CmWidgets.  The fact that this is the only
output from the Navigator to the rest of CDS allows one to make changes
to the Navigator without affecting the rest of CDS.  This allows future
developers to easily make improvements to the Navigator module.

\section{Internal Structure of the Navigator}

\section{Overall Design}
The Navigator is designed so that its various function are kept as separate
as possible so that one part of the Navigator can be improved without
making changes to the other parts of the Navigator.

As a result, the Navigator is implemented as three interacting submodules.
These submodules are implemented as C++ classes, each dealing with a specific
aspect of the Navigator's function.

These three submodules are:
\begin{itemize}
\item The NavigatorOutliner, which is responsible for keeping the
structure of the Nodes

\item The NavigatorHeap, which is the storage of the Nodes, and

\item The NavigatorParser, which is responsible for loading and saving the
Nodes to and from the file system
\end{itemize}

The internal structure of the Navigator can be diagrammed as follows

\begin{figure}
\PSbox{/mit/cds/theses/joe/navigator.idraw hscale=0.7 vscale=0.70}{6in}{6in}
\caption{Structure of the Navigator}
\end{figure}

As we have seen above, the Navigator can receive command either from the
model or from the user.  These commands are of two types.  One type is a
command to display a different Node.  The other is a command to load or
save the current lecture onto disk.

When the Navigator receives a command to display another Node, the
NavigatorOutliner processes the command and finds the title of the
node which is to be displayed.  This title is sent to the NavigatorHeap
which retrieves the Node pointer corresponding to the title.  This 
Node pointer is then sent to the CmWidgetEditor.  Because the storage
of the Nodes is separate from the organization of the Nodes, improvements
to the Navigator, such as the addition of outlining and cross-referencing,
can easily be made by changing the NavigatorOutliner.

If the Navigator receives a command to load a file, it calls the appropriate
procedures in the NavigatorParser, which loads in the file, and changes the
NavigatorOutliner and NavigatorHeap so that they contain the nodes of the
load file.

Now that we have examined the general function of the Navigator, we can
examine each of the submodules in particular.

\section{The NavigatorOutliner}
The NavigatorOutliner is responsible for organizing the Node into
a tree structure.  It takes input from the user regarding navigating
through the tree structure.  It outputs a string that contains the
title of the node that is desired.

Internally, the names of the nodes are stored in a linked list in the
NavigatorOutliner.  Each element of the linked list contains the
name of the node and a number denoting the level on the outline of the
node.

\section{The NavigatorHeap}

The NavigatorHeap contains pointers to the nodes.  It takes as input a
CmString containing the title of the node to be retrieved and outputs a
pointer to the node itself.  This pointer is sent by Navigator to the
CmWidgetEditor which displays the referenced Node.

Future extensions to the NavigatorHeap may include retrieval of
nodes by keywords.

Like the NavigatorOutliner, the NavigatorHeap also uses a List
to hold the Nodes which exist within the heap.  However, the List
is merely used as a convenient storage device.  The ordering of the
Nodes in the List in the NavigatorHeap is not used for any purpose.

\section{The NavigatorParser}
\subsection{The Lecture File}
It was decided that the CDS file be a file that is coded in ASCII
rather than coded in a binary format.  An ASCII format causes the
loading and saving of files to be somewhat slower than a binary
format.  However, because these files can be read with UNIX utilities
such as 'more' and edited with a text editor such as 'emacs'.

Furthermore, different machines have different conventions regarding
the ordering of the bytes in a data file.  Thus, a binary file would
not be portable across machines.  For these reason, the disadvantage
of slower loading is far outweighed by the advantage of lecture file
maintainence.

\subsection{YACC and LEX}
There were two possibilities in implementing the NavigatorParser.
The first was to use a preprocessor that would take a description of
the parsing language and convert it into c++ code.  The second was to
write a c++ class directly in C++.

The disadvantage in using a preprocessor was that no such preprocessor
existed for c++.  The closest thing available was YACC and LEX.  YACC
takes a file that describes the grammar of the language in LRLR form
and produces a C file from it.  LEX takes a file that describes the
regular expressions of the elements of the language and converts it
into a C file that scans the file for the regular expressions and
finding them converts them to tokens that are used by YACC.

Unfortunately, the other option of writing a parser in c++ code seemed
more undesirable.  From our experience with LAS, we concluded that a
parser that was written directly using a general programming language
would be nearly impossible to maintain, and would be inflexible
to changes in the language of the input file should they be deemed
necessary.

To resolve this dilemma, it was decided that we would use YACC and LEX
to produce a C file, that they would be sent through a processor
written by the CDS design team that would do string replacements to
convert the C file into C++ code.

The grammar of the NavigatorParser is a YACC grammar.  To compile
the parser, the file NavigatorParser.yacc is pre-processed by the
UNIX utility YACC that takes an LRLR grammar converts it into C-code.
The file NavigatorParser.lex is also thus processed by the utility
LEX.  These two files are then concatenated into a file that is run
through a string replacement script that converts the C-file into C++
code that describes a C++ class.

Because the processed file describes a c++ class, a program may have
several independent parsers.  Something that is not allowed by the
files generated directly from lex and yacc.

\section{Conclusion}
This semester, I was successful in implementing a Navigator with
minimum functionality.  In the next chapter, I will list some of the
possible extensions to the current Navigator.

\chapter{Future Developments} 
Right now, the Navigator is at a relatively primitive stage of
development.  Many features should be added to the Navigator to
improve its functionality.

\section{More Flexible Ordering}
Currently, the user can only append Nodes to the end of the displayed
lecture, and cannot change the order on the Nodes once they are
created.  This is a serious limitation to CDS and should be corrected
by future developers.

\section{Use Standard Utilities To Create Parser}
The NavigatorParser was implemented using nonstandard methods describe
in the previous chapter.  Currently there are developers who are
working on converting FLEX and BISON, programs which work like LEX and
YACC, into utilities which can generate C++ classes.  When these
utilities become available, it would be good to switch to them.

\section{Better Error Handling}
Currently, the NavigatorParser has no error handling.  If the format
of the file does not match what is expected by YACC and LEX, the
NavigatorParser will output ``syntax error'' and return control to
the Navigator.  Although all lecture files are currently generated
by CDS, thus minimizing the possibility that an invalid file would be
created, it would still be good programming practice to program the
NavigatorParser in such a way that it will salvage as much as
possible from a corrupted lecture file.

\section{Dynamic Loading of Nodes}
The NavigatorParser loads in all Nodes belonging to a given
lecture file.  It is possible to modify the Navigator to only load
in the Nodes as needed.

\section{Outlining}
The Nodes are currently arranged by the Navigator into a flat
list.  This makes it difficult to organize large numbers of Nodes.
It would be better if the NavigatorOutliner could arrange the
Nodes into a tree structure.  This would allow the lecture file to
be organized similar to a book with some Nodes representing chapter
headers, others representing sections, sub-sections and so forth.

Ideally, the lecturer would deal with the outline structure through a
WYSIWYG interface similar to PC-Outliner or the outliner in Microsoft
Word.  By using mouse clicks and drags, the lecturer ought to be able
to rearrange the chapters and sections of the lecture.

\section{Indexing and Cross-Referencing}
The current Navigator does not have the ability to cross-reference
node nor does it have the ability to reference screens by keywords.
This functionality may be added by modifying the NavigatorHeap.
In the future the Navigator may have the ability to search across
different lecture files, generating indexes so that the user can look
up related subjects.

\section{Printed Text Output}
It may be possible to modify CDS so that it can be used by a lecturer
to create a textbook.  CDS would then generate a TeX file which could
be typeset.

\section{Graphical Objects}
The Node could be modified to not only hold CmWidget objects, but
also graphical objects such as circles, rectangles, etc.  A
``palette'' could be added to CDS so that it will have the
functionality of a graphics program such as idraw or MacDraw. 

\section{Hypertext Processor}
CDS could be modified to give it some word processing capabilities.  With this
addition, CDS could then be used to generate hypertext as easily as word
processors generate traditional documents.  Such a processor would greatly
impact communications.

\appendix

\chapter{Glossary}
{\bf C++} - Language which is based on C, but which contains
structures which make object-oriented programming easier.  The
Courseware Development System is written using C++.

{\bf Courseware Development System} - A program which is designed to allow
college lecturers design their own courseware

{\bf CmWidget} - A graphics object within CDS which is analogous to a figure
or a piece of text in conventional media.

{\bf CmWidgetEditor} - An object within the Courseware Development System
which display and edits graphics objects known as CmWidgets.

{\bf MOTIF} - A graphical user interface designed by the Open Software
Foundation.  A set of widgets has been implemented by OSF to allow
software developers to use MOTIF as the graphical user interface for
their programs.

{\bf Navigator} - Object within CDS which is responsible for organizing the
Nodes into an outline.

{\bf NavigatorHeap} - Object within the navigator which retrieves a pointer to
a node when given the title of the node

{\bf NavigatorOutliner} - Object with the navigator which takes commands from
the user or from the model and output the name of the node which is to be
retrieved.

{\bf NavigatorParser} - A submodule of the Navigator which is
responsible for loading a lecture file from disk and creating Nodes
which correspond to the description in the file.
 
{\bf Node} - An object within CDS which is analogous to a page in a book or
a transparency

{\bf resource} - An attribute of a widget

{\bf Widget} - (not to be confused with CmWidget) A widget is the
basic unit of the Xt Toolkit.  A CmWidget contains a Widget and the
text needed to create the widget.

{\bf X11 Window System} - Window system used by the MOTIF GUI

\chapter{Appendix - CDS File Format}

The following is an example lecture file
Anything beginning with a \\ is considered a control command

\begin{verbatim}
\CDS_Version "btest"
\end{verbatim}

The first thing in a CDS lecture file is a string containing th
version number of the CDS file.  This allows CDS to inform the user
about incompatibilities between lecture files.

\begin{verbatim}
\begin_outline
"Introduction to CDS"
"The Widget Periodic Table"
"Fuzzy Wuzzy"

"Plotter"
"Other Goodies"
\end_outline
\end{verbatim}

The above section contains the list of screens in the lecture file.
The purpose of this is so that the Navigator can check if a file
exists in a particular lecture file without scanning the whole file.
If the lecture file does not see a \\begin\_outline or \\end\_outline it
will go ahead and build it's own from the list of screens.

\begin{verbatim}
\begin_node{untitled0}
\title{Introduction to CDS}
\begin_screen
\end{verbatim}

This tells CDS to begin a node named ``Introduction to CDS''.  The
name after \\begin\_node exists only of historical reasons and is not
used be any part of CDS.

\begin{verbatim}
\keywords{List}{of}{keywords}
\end{verbatim}

The token keyword is recognized by the NavigatorParser.  It is not
used however, and exists only as a stub for future expansion.

\begin{verbatim}
\begin_screen
\end{verbatim}
This tells the NavigatorParser that the next section is a list of
CmWidgets.  The part of the lecture file between \\begin\_screen and
\\end\_screen is not processed by the NavigatorParser.  It is merely
placed into a buffer inside the Node for the WidgetEditor to process.

\begin{verbatim}
\begin_figure {XmLabel}
\widget_name "untitled0_XmLabel0
\mapping "True"
\constructor_text ""
foreground "maroon";
background "gray";
borderWidth "0";
labelPixmap "/mit/cds/beta/pixmaps/mit-logo";
labelString "Default Label";
labelType "PIXMAP";
leftPosition "318";
topPosition "60";
rightPosition "651";
bottomPosition "396";
\end_figure
\end{verbatim}

This is a typical description of the CmWidget.  

\begin{verbatim}
\end_screen
\end{verbatim}

This tells the NavigatorParser that a screen definition is complete.

\begin{verbatim}
\end_node
\end{verbatim}

This tells the NavigatorParser that a node is complete.

\nocite{ellisman}

\chapter{User Interaction With CDS on the Project Athena System}
The operation of CDS can best be illustrate by stepping thorough a
typical CDS session.  A user can start by attaching the cds locker
through the ``setup cds'' script.

\begin{verbatim}
athena% setup cds
\end{verbatim}

This will bring up a window with a menu.  By choosing the appropriate menu 
item one can start up the current version of CDS.

CDS then initializes and brings up a blank screen.  \begin{figure}[htb]
\PSbox{/mit/cds/theses/joe/fig6.PS hscale=0.7 vscale=0.7}{6in}
	{5in}
\caption{Blank Screen of Courseware Development System}
\end{figure}

\newpage
By bringing down a menu option, we can bring up a dialog box and load
in a file.  After loading the file, this is what we get:
\begin{figure}[htb]

\PSbox{/mit/cds/theses/joe/fig1.PS hscale=0.7 vscale=0.7}{6in}
	{5in}

\caption{Startup Screen of Courseware Development System}
\end{figure}

\newpage
The Navigator controls the area at the bottom of the screen.  It
currently consists of three parts, the Previous button, the list box, and
the Next button.  The nodes in CDS are arranged in a linear sequence.  In
the future, we hope make the Navigator more sophisticated by adding several
features which are detailed in Chapter 5.

One can view the next node by pressing the arrow marked Next with the left
mouse button.

\newpage
\begin{figure}[htb]
\PSbox{/mit/cds/theses/joe/fig2.PS hscale=0.7 vscale=0.7}{6in}
	{5in}

\caption{The Widget Periodic Table}
\end{figure}

This screen displays several of the different CmWidgets which are available
on CDS.  These CmWidgets can be editing by using the middle button.  By double
clicking on a CmWidget, one can bring up a dialog box, which can change the
attributes of the CmWidgets.  For example, after double clicking on the
widget marking {Label}, the screen looks like the following:

\newpage

\begin{figure}[htb]
\PSbox{/mit/cds/theses/joe/fig3.PS hscale=0.7 vscale=0.7}{6in}
	{5in}

\caption{CDS with the dialog box}
\end{figure}
\newpage

We can then edit the label by moving the mouse into the text box next to
``Label:'' and changing what is there.  By a simple mouse click we 
can also change the font.


\begin{figure}[htb]
\PSbox{/mit/cds/theses/joe/fig4.PS hscale=0.7 vscale=0.7}{6in}
	{5in}

\caption{The dialog box after our changes}
\end{figure}

\newpage
Then clicking ``OK'' we see that our changes have been made:

\begin{figure}[htb]
\PSbox{/mit/cds/theses/joe/fig5.PS hscale=0.7 vscale=0.7}{6in}
	{5in}
\caption{Our changes}
\end{figure}

\nocite{stroustrup}

