\documentclass{article}[11pt]
\setlength{\topmargin}{-2cm}
\setlength{\textheight}{24cm}
\setlength{\oddsidemargin}{10mm}
\setlength{\evensidemargin}{10mm}
\setlength{\textwidth}{15cm}
\setlength{\parskip}{3mm}
\setlength{\parindent}{0mm}

\usepackage{epsfig}
\usepackage{comment}
\usepackage{graphics}
\usepackage{graphicx}
\usepackage{hyperref}

\newcommand{\Rfunction}[1]{{\textsf{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textit{#1}}}
\newcommand{\Rslot}[1]{\textsl{#1}}
\newcommand{\Rclass}[1]{\texttt{#1}}
\renewcommand{\baselinestretch}{1.5}

\begin{document}

\bibliographystyle{amsplain}


\author{Elizabeth Whalen\\Harvard School of Public Health}
\title{Creating Linked, Interactive Views to \\ Explore Multivariate Data} 

\maketitle

\begin{abstract} 
  Visualizing data is an important component of exploratory data analysis.
  Ideally, one would be able to create views of the data, interact with those
  views to find interesting data points, and then perform statistical
  modeling of the data all within the same system.  In this paper, we present
  two new \textsf{R} packages, \Rpackage{MVCClass} and \Rpackage{iSPlot},
  that allow users to create linked, interactive views of multivariate data.
  Most importantly, the software was designed to be extensible using the
  model-view-controller paradigm to create linked views. We rely on 
  two other \textsf{R} packages, \Rpackage{RGtk} and \Rpackage{gtkDevice},
  to create interactive views.  This extensibility, which can be performed
  solely in the \textsf{R} language, lets developers create interactive
  views from the statically available plots in \textsf{R} 
  and new responses to user interactions, such as changing the response to a
  left button click from coloring a point to hiding a point.  In addition,
  since these packages are available in \textsf{R}, the user can perform
  statistical modeling in the same system as the exploratory data analysis.
\end{abstract}

\section{Introduction}\label{Sec:Intro}
\subsection{Background}\label{Ssec:Backg}
\noindent

A graphical display is a powerful tool to more thoroughly understand
data \cite{GraphicalMethods}, by assisting in such tasks as spotting outliers
and finding patterns in the data structure.  However, traditional computer
graphics  are limited to the two dimensional plane provided by the computer
screen.  This limitation is clearly a problem for visualizing multivariate
data.  Fortunately, there are many ideas about how to simulate
multi-dimensional views of data \cite{GraphicalMethods} including rotation,
the use of small multiples \cite{VisualDisplay}, scatter plot matrices, and
linking. 

One idea for viewing multivariate data is called small multiples.  In
small multiples, a series of graphics displays the same combination of
variables, but each graph in the series is indexed by another
variable \cite{VisualDisplay}.  For instance, the series of graphics
could be a series of county maps, where each map is colored by the
amount of pollution emissions at a particular time.  Thus, the user
can see how the pollution emissions change over time by studying how
the graphs change through the series.  This idea is spatially
appealing, but is limited in the number of variables that can be
displayed.  

A similar idea to small multiples is an idea called conditioned
choropleth maps.  Conditioned choropleth maps are graphs that display
two explanatory variables and one dependent variable \cite{CC}.  An
example of a conditioned choropleth map is a series of maps of the
United States, where each map is indexed by an annual precipitation
level and a percent below poverty level, and on each map is shown
concentration of lung cancer mortality rates.  In this example, the
two explanatory variables are the annual precipitation level and the
percent below poverty level, and the dependent variable is the lung
cancer mortality rate.  

Other ideas that are similar to small multiples and conditioned
choropleth maps are conditioning plots and Trellis graphics.  In
conditioning plots, which are implemented in \textsf{R} with the function,
\Rfunction{coplot}, a series of graphs are conditioned on one or two
variables.  One example is a series of graphs showing latitude versus
longitude of earthquake locations while the depth of the earthquake is
the conditioned variable.  Thus, the graphs of latitude versus
longitude are shown at different ranges of depths (the conditioned
variable).  This example is shown below in Figure \ref{Fig:Quake}.
Trellis graphics, which were created to provide graphical
representation of the relationship between several variables through
conditioning, can produce multi-panel, multi-page graphs \cite{Rnews}.
Thus, Trellis graphics are based on the same idea as conditioning plots.

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.33}{\includegraphics{Quake.jpg}}
    \caption{ Conditioning plots example. }
    \label{Fig:Quake}
  \end{center}
\end{figure}

Another idea for displaying data with more than three variables is
called generalized draftsman's display, where an array of scatter plots
\cite{GraphicalMethods} is created.  If the data set had four
variables, then a four by four array of scatter plots is created
and any adjacent pairs of plots have an axis in common
\cite{GraphicalMethods}.  For example, in the first row of the four by
four array, the first scatter plot is variable 1 vs. variable 1,
the second scatter plot is variable 1 vs. variable 2, the third
scatter plot is variable 1 vs. variable 3, and the fourth
scatter plot is variable 1 vs. variable 4.  Then in the second
row of the four by four array, the first scatter plot is
variable 2 vs. variable 1, the second scatter plot is variable 2
vs. variable 2, and so on.  Generalized draftsman's display is the
plotting method used when plotting a data frame in \textsf{R}.  In Figure
\ref{Fig:USArrests}, an example of a generalized draftsman's display
is shown for a data frame called USArrests that has the four
variables: Murder, Assault, UrbanPop and Rape.  The
disadvantage with this method is that it can be difficult to determine
which points in different scatter plots refer to the same entity
(i.e. the same row in a data frame).  Also, the greater the number of
variables, the more scatter plots created, which can become overwhelming. 

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.4}{\includegraphics{USArrests.jpg}}
    \caption{ Generalized draftsman's display example. }
    \label{Fig:USArrests}
  \end{center}
\end{figure}
  
Using multiple-code symbols on a scatter plot \cite{GraphicalMethods}
is another method to display multivariate data.  Here, one scatter plot is
created, but different symbols are used for the data points to show
the value of that point in reference to a third variable.  For
instance, the scatter plot may show variable 1 vs. variable 2, but the
data points are drawn on the scatter plot with an X if they are from a
female or an O if they are from a male.  Thus, this scatter plot now
displays information for three variables.  Clearly, this method is
limited because as the number of variables increases, it requires
many different plotting characters to display so much information on
one plot.

Yet another possibility is to create multiple plots that are linked.
Linked plots mean that if a point on one plot changes its appearance,
such as it becomes colored red, then the corresponding point on a
second plot also changes its appearance to the color red.  For
points to be corresponding, the data displayed in the points must come
from the same entity.  As an example, one person's height, weight,
age, and cholesterol level are data from the same entity.  Thus,
if one plot had height versus weight and a second plot had age versus
cholesterol level, then the point on plot one and the point on plot two
which referred to the same person are corresponding points. 

Although creating linked plots allows more than two variables to be
studied visually at the same time, a tool that implemented this idea
is even more useful if it also allows these plots to be interactive.
Interactivity is an idea that is familiar from using an Internet browser.
Clicking on a hyperlink on a web page results in a new web page opening.
Another example is clicking on the login button after entering a user name and
password to view one's email.  Interactivity means that there is a response to
some user action.  This idea is used in many applications, not just the
Internet.  Another example is double clicking on an icon on one's
desktop to open a document or an application.

One particular model for creating interactive applications involves three
components: some user action or input, which is referred to as an event;
a response to that action, which is executed by a function that is called
a callback function; and a method that connects the event to the callback
function, which is referred to as the signal handler.  The events can
range from the user moving the cursor over a plot, to pressing a button on a
graphical user interface (GUI), to pressing certain keys.  Events are
interpreted based on which window has focus.  For example, in the X Windows
system, if a user types C on the keyboard and the window that has focus is a
text editor, then the letter C is printed on the text editor's screen.
Any other open windows that do not have focus do not respond to this event.
The callback function is a unique function because its signature is determined
by the event that the callback function is linked to.  The parameters passed
to the callback function may include information about the event, such as the
on screen location of the event, and information about the object that had
focus when the event occurred, such as a button on the GUI.  The signal
handler is the piece that must look to see if an event has occurred and then
when the event has occurred, the signal handler calls the appropriate callback
function. 

The strengths of this model of interactivity are that programmers can decide
which events to react to by deciding which signal handlers to implement,
programmers can change the response to an event by changing the callback
function that is linked to an event, and the system's event loop can continue
working on other things until a signal is emitted when an event occurs.  A
system's event loop controls how work is processed.  The event loop checks for
work to do and handles that work.  In the model of interactivity described
above when a signal handler is implemented by the programmer, this results in
the event loop periodically checking to see if an event has occurred.  Thus,
the event loop can perform other work and then check back to see if an event
has occurred.

These three pieces in this model of interactivity are ordered as follows:
an event occurs, the event causes a signal to be emitted that is caught by the
signal handler, and then the signal handler calls the callback function, which
results in the response to the user action.  A flowchart of these steps is
shown below in Figure \ref{Fig:Event}.  In the example of clicking on a
hyperlink mentioned above, the event is the user clicking on the
hyperlink and the callback function causes a new web page to open.
The signal handler, which is the method that connects the event to the
callback function, is handled by the system's event loop when a signal is
emitted. 

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.55}{\includegraphics{Event.jpg}}
    \caption{ Flow chart of the response to an event. }
    \label{Fig:Event}
  \end{center}
\end{figure}

In this paper, after reviewing the design and capabilities of current
software to visualize multivariate data, two new \textsf{R} packages, called
\Rpackage{iSPlot} and \Rpackage{MVCClass}, are discussed.  This discussion
includes why these packages were created, the goals of these packages, and
the design of these packages. 

\subsection{Current Tools/Software}\label{Ssec:CurTools}

Many tools already exist to view multivariate data.  The tools that
are discussed here are: 

\begin{itemize}{}{\setlength{\leftmargin}{0.5in}
               \setlength{\itemsep}{0in}}
  \item \Rfunction{identify} and \Rfunction{locator}, which are \textsf{R} functions
  \item \Rpackage{iPlots}, which is an \textsf{R} package
  \item MANET, which is \textsf{C++} software for a Macintosh
  \item MONDRIAN, which is a \textsf{JAVA} application
  \item GGobi, which is a stand-alone application written in \textsf{C} 
  \item XLisp-Stat, which is a statistical environment built on top of \textsf{XLisp}
\end{itemize}

Ideally, software for visualizing multivariate data also performs
statistical analyses and allows user interaction, linking of views, and future
extensions. 

\subsubsection{\Rfunction{Identify} and \Rfunction{Locator}}
\label{Sssec:Identify}

To support interactivity with plots, \textsf{R} contains the two functions,
\Rfunction{identify} and \Rfunction{locator}.  Both functions return
information about where the left mouse button was pressed on a plot.

The purpose of the \Rfunction{identify} function is to determine
(or identify) which points a user has clicked in a plot.  To do this,
\Rfunction{identify} reads the position of the graphics pointer when
the left mouse button is pressed.  \Rfunction{identify} either
requires the parameters, x and y, which are the vectors containing the
coordinates of the points in a scatter plot, or it requires only one
parameter, x, which is an object that defines coordinates on the plot,
such as a plotting structure or a time series object.  The return
value from \Rfunction{identify} is an integer vector containing the
indeces of the identified points.  If no points were clicked, then the
vector is empty.  To identify a point, the position clicked on the
plot must be within 0.25 inches of the point. \Rfunction{identify} is
a modal function, which means that \textsf{R}'s processor waits until
\Rfunction{identify} is finished before performing other computations.
\Rfunction{identify} stops when one of the following situations
occurs: the middle or right mouse button is pressed, all points have
been identified, or when the number of points identified is equal to
n, which is an optional parameter to \Rfunction{identify}.  The
default value for n is the length of the parameter x.

The purpose of the \Rfunction{locator} function is to read the position of
the cursor when the left mouse button is pressed.  Thus, unlike
\Rfunction{identify}, \Rfunction{locator} is not trying to identify
points.  \Rfunction{locator} is only returning the location of mouse clicks.
\Rfunction{locator} requires no parameters, though there is an
optional parameter, n, which is the maximum number of mouse clicks to
locate.  The default value for n is 512.  \Rfunction{locator} returns
a list of x and y components, which are the user coordinates of the
positions pressed.  As with \Rfunction{identify}, \Rfunction{locator}
is a modal function and it stops when the middle or right mouse button
is pressed, or when the number of positions clicked is equal to n. 

Both \Rfunction{identify} and \Rfunction{locator} are a good first
start at interactivity in \textsf{R}, but there are drawbacks.  Once either
function is called, it waits until a certain number of mouse
button press events have occurred and the programmer may not know ahead of
time how many times the user wants to click on a plot.  Since
these functions are modal, if the user presses the key ``Q''
while these functions have control of \textsf{R}'s processor, the event
is not processed until after these functions are finished.  Although it is
possible for the user to end the functions by clicking on the second or third
mouse button, this action is not intuitive.  The user should be driving the
interactivity and that is not possible with these functions.

Also, these functions only recognize a mouse button press event so other
events, such as a mouse over event, cannot be responded to.  Thus, the amount
of interactivity that can be created in an application that depends only on
\Rfunction{identify} and \Rfunction{locator} is limited.

\subsubsection{\Rpackage{iPlots}}\label{Sssec:iPlots}

\Rpackage{iPlots} is an \textsf{R} package that creates interactive, linked
plots using \textsf{Java} \cite{iPlots} and can be found at the following URL,
\url{http://stats.math.uni-augsburg.de/iPlots/}.  The \Rpackage{SJava}
package is required by \Rpackage{iPlots} to access the plots created
using \textsf{Java}.  \Rpackage{iPlots} allows the user to create several types
of interactive plots, such as scatter plots, bar charts, and
histograms.  In addition, the creators of \Rpackage{iPlots} intend to
implement more plots in future releases of \Rpackage{iPlots}.  Once
multiple views have been created the user can interact with the views
with actions such as highlighting and brushing points.

\Rpackage{iPlots} gives the user the power to perform statistical
analyses on the data since \Rpackage{iPlots} is linked to \textsf{R}, but
there are limitations in the design of the package.  In
\Rpackage{iPlots}, data sets are composed of an arbitrary number of
vectors \cite{iPlots}, where each vector represents a variable.
Whenever the user creates a new plot, the data that the new plot uses
are compared to the length of the current data set.  If the lengths are
the same, then the new data are added to the current data set.  The
goal of this design is to reduce overhead for the user so the user is
not forced to bind data together in a data frame ahead of time.
However, comparing the length of the new data with the current data,
as the criterion for determining whether they are from the same
data set, may cause errors.

Also, the current implementation of \Rpackage{iPlots} defines all the
user interactions and thus, new responses to events cannot be changed
through \textsf{R}.  For example, clicking the mouse over a plot always selects
or highlights the object located at the mouse position.  This means
that if the mouse is clicked while the cursor is over a point on a
scatter plot, then that point is selected.  Allowing a user to
change what happens when a mouse click occurs makes the package
more flexible. 

Currently, the callback functionality of the \Rpackage{SJava} interface
is not exposed to the user \cite{iPlots}, which means that there is no
signal thrown to \textsf{R} when an event occurs and thus, the user cannot
connect an event with a callback function.  Recall that events and
callback functions were discussed in Section \ref{Ssec:Backg}.
Because the callback functionality is not exposed, the user cannot
create a function that is called whenever a mouse button press event
occurs and thus, the functionality that occurs when the mouse is
clicked is fixed. However, according to the \Rpackage{iPlots}
documentation this functionality will be available in future releases. 

\subsubsection{MANET and MONDRIAN}\label{Sssec:ManMon}

MANET is a software package written in \textsf{C++} that runs on the Macintosh
Operating System \cite{MANET}.  MANET provides the capability to create
interactive plots of categorical data, particularly focusing on mosaic
plots, though other plots such as bar charts, histograms, trellis
plots and scatter plots are available.  Mosaic plots \cite{Mosaic} allow
visualization of n-way contingency tables by creating rectangular
regions whose area is proportional to the frequency in a cell.  An
example of a mosaic plot is shown in Figure \ref{Fig:Mosaic}.

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.6}{\includegraphics{titanic.jpg}}
    \caption{ A mosaic plot of survival on the Titanic. }
    \label{Fig:Mosaic}
  \end{center}
\end{figure}

In Figure \ref{Fig:Mosaic} the survival on the Titanic is split based on
gender (male vs. female), class (1st, 2nd, 3rd, or crew) and
age (adult vs. child).  The coloring on the plot shows those who
survived as yellow and those who did not survive as red.  From this
visualization it is clear that women and children were more likely to
survive, but so were those in higher classes.

Although the mosaic plot is a powerful method for depicting
multivariate categorical data, the impact of the plot
depends on the order of the variables.  Figure \ref{Fig:Mosaic} is a
static depiction of a mosaic plot, but the MANET software lets the
user interact with a mosaic plot to change the order of the variables
in the plot through drag \& drop in a list or by keyboard control
\cite{MANET}.  Changing the order of the variables is similar to the
idea of rotating a 3-dimensional space for continuous data.  Thus, by
making the mosaic plot interactive, the user is quickly able to derive
more information about the structure of the data.

MANET also focuses on innovative methods for visually depicting
missing values.  For example in a histogram or bar chart an extra bar
\cite{MANETMV} can be added to show a missing value category.  Missing
values have also been incorporated into other plots, such as box plots
and scatter plots. 

MONDRIAN, which can be found at
\url{http://www.theusrus.de/Mondrian/index.html}, is an extension of the
MANET software, but MONDRIAN is written in \textsf{JAVA} \cite{MONDRIAN} so
that it is platform independent.  Similar to MANET, MONDRIAN focuses
on visualizing categorical data, but also now includes geographical
data \cite{MONDRIAN}.  Views that can be created in MONDRIAN include
bar charts, mosaic plots, maps, scatter plots, and parallel coordinate
plots.  As with MANET, the plots created in MONDRIAN are interactive
and some examples of interactivity include a right mouse button click
resulting in a pop-up window, zooming in and out using control-click
and drag on the plot, and brushing by creating a selection rectangle
on the plot and then dragging that rectangle over the plot.  Also,
plots that are based on the same data set are linked so a case
selected in one plot is selected in other plots.

Both MANET and MONDRIAN are powerful tools for visualizing categorical
data through the many views that can be created and through the large
number of options for interactivity of these views.  Also, since
MONDRIAN is written in \textsf{JAVA}, users on any operating system can use the
software.  However, since MANET and MONDRIAN focus on presenting
categorical data, users with continuous data need to use a
different software package to provide interactive, linked views of
their data.

\subsubsection{GGobi}\label{Sssec:Gobi}

GGobi, which can be found at \url{http://www.ggobi.org/}, is a stand-alone
data visualization system that creates interactive and dynamic views
of data \cite{GGobi} using \textsf{C} and Gtk+.  In GGobi, users can create
multiple linked and interactive views of the data through a graphical
user interface that contains menus.  For example, using the Display menu,
views such as scatter plots, time series plots, parallel coordinate plots, dot
plots, spline plots, and bar charts can be produced.

Once one or more views have been created, the ViewMode menu in
GGobi lets the user set the projection and the interaction type
\cite{GGobi}.  The projection options set the view dimension.  For
example, one dimension views include dot plots and histograms, while two
dimension views include scatter plots.  Then tours of these views can
be performed using the ViewMode menu items, such as 1-D tour and 2-D
tour.  These options not only give the user different ways of
displaying the data, but also let the user see the data through
rotation. 

The other menu items available through the ViewMode menu in GGobi
allow the user to change what happens in response to interaction with
a view.  For example, the user can decide to scale axes, brush
rectangular regions, identify points and lines, and move points
through interacting with a view after setting these options in the
ViewMode menu.  Another example of interaction allowed by GGobi
includes allowing the user to pan and zoom views.  

GGobi also gives the user many options to manipulate the data and its views.  
These options include allowing a user to directly change data through a
spreadsheet view, to subset the data by case, and to manipulate variables,
such as performing a variable transformation.  Within each plot type,
such as scatter plot and bar chart, the user is given many options of altering
plotting parameters.  The user also has the option of changing how points are
linked.  Points can be linked either through ID or by variable
\cite{GGobiMan}.  Linking by ID, which is the default, means that points
representing records with the same ID are linked.  Linking by variable
uses the levels of a categorical variable to link points \cite{GGobiMan} so
points with the same value for a categorical variable are linked.  Because
the user has so much flexibility in how the data are displayed, GGobi is a
very powerful tool to view the data and find relationships among the
variables. 

Although GGobi allows the user many ways of viewing and interacting
with the data through its extensive menus, it does not include any
statistical analysis tools so the user cannot perform calculations on
the data.  This aspect of the design was deliberate as GGobi was
intended to be a stand-alone application that excelled in displaying
data.  However, having one location where data can be both analyzed
and displayed is helpful to users that want to perform both
tasks.  Theoretically, GGobi can be linked to \textsf{R} using the
\Rpackage{Rggobi} package, although in practice this has been difficult.  

\subsubsection{XLisp-Stat}\label{Sssec:Lisp}

Lisp-Stat is an object-oriented environment based on \textsf{Lisp} that allows
the user to perform statistical analyses as well as create dynamic
graphics.  Lisp-Stat is a general specification while XLisp-Stat is an
implementation \cite{Lisp} that is built on top of the \textsf{XLisp}
programming language, which is a dialect of \textsf{Lisp}.  XLisp-Stat runs on
several operating systems, including Macintosh, Windows, and Unix.
Information about obtaining Lisp-Stat can be found at
\url{http://www.stat.uiowa.edu/~luke/xls/xlsinfo/node1.html} and XLisp-Stat is
available by anonymous ftp to \url{ftp.stat.umn.edu/pub/xlispstat}.

One of the primary reasons for creating XLisp-Stat was to produce an
environment for experimenting with dynamic graphics \cite{XLisp} while
integrating the capacity for statistical analyses.  Thus, this environment
needed to be built with a programming language and \textsf{Lisp}, a well
understood functional language \cite{XLisp}, was chosen.  \textsf{XLisp}, in
particular, became the basis for the XLisp-Stat software because it is
available for unrestricted, non-commercial use, it is small for a
\textsf{Lisp} system, its source code is available in \textsf{C}, it is easily
extensible, and it includes support for object-oriented programming
\cite{XLisp}. 

A session with XLisp-Stat consists of the user typing in commands at the
prompt \cite{XLisp}, though a user can use menus and
dialog boxes to create a GUI.  Static plots of data can
be created, such as scatter plots and histograms, but the user can also choose
to interact with these plots.  By interacting with these plots, the user can
start to explore three or more dimensions visually.  For example, the user can
spin a scatter plot to simulate a three-dimensional scatter plot.  The
spinning causes the points in the two-dimensional plot to rotate around some
axis.  The user can also choose the rotation speed through key press events.
For example, Command-F speeds up the rotation \cite{XLisp}.  Another example
of visualizing more than two dimensions is allowing scatter plots to be
linked.  This linking can be accomplished through selecting or brushing
points in one scatter plot and seeing corresponding points selected in the
other scatter plots.  Users can also remove subsets of points from plots and
they can also show labels over points in a plot.  

Yet another example is that users can create a dynamic simulation of their
data.  Here a list of indices is run through and any points corresponding
to those indices are highlighted as the indices are chosen.  Thus, the
user can focus on how the points in the different views are linked, rather
than focusing on interacting with one plot via the mouse. 

Even with the large amount of built-in functionality in the XLisp-Stat system,
the user can create additions because it is built on a programming language.
However, the syntax of \textsf{Lisp} is not as familiar to many users
\cite{LispStat} and thus, learning to program in \textsf{Lisp} is often
perceived as an impediment.  Also, \textsf{Lisp} does not provide a
well-defined mechanism for extending the language with domain-specific
libraries \cite{LispStat}, which limits the amount of user supplied software
to extend the capabilities of Lisp-Stat. 

\subsection{From Current Tools to \Rpackage{iSPlot} and \Rpackage{MVCClass}}\label{Ssec:From}

Given the state of the current tools, creating new \textsf{R} software that
could implement linked, interactive views with an extensible design
would be useful for performing exploratory data analysis on multivariate
data.  According to the goals mentioned in Section
\ref{Ssec:CurTools}, the software should be able to visualize
multivariate data, allow for user interaction, perform statistical
analyses, and allow for future extensions.  And it is extensibility
that sets this research apart from the projects discussed above.

All software is, by its nature, extensible as long as developers have access
to the code.  However, the goal here is to create an extensible system where
developers only need to be familiar with one language to make changes.  By
requiring developers to only know the \textsf{R} language, the hope is that
users will make additions based on the needs of their data.  The design of
this system was carefully implemented so that users can create new potential
responses to an event, can change the response to an event, can add new views,
and can add new data types all within the \textsf{R} language.

Deciding to create the software in \textsf{R} was a natural choice because of
\textsf{R}'s statistical analysis capabilities and its ability to create
publication-quality plots.  However, as mentioned in Section
\ref{Sssec:Identify} the only interactivity currently implemented in \textsf{R}
are the functions, \Rfunction{identify} and \Rfunction{locator}, which
can only respond to a mouse button press.  Fortunately, by combining
two \textsf{R} packages, \Rpackage{RGtk} and \Rpackage{gtkDevice}, it is
possible to create interactive views that can respond to many events.
Finally, by carefully implementing a paradigm called model-view-controller
(MVC), the design is flexible enough for future additions.  These ideas are
discussed further in Section \ref{Sec:Design}. 

\section{Design of the \textsf{R} packages, \Rpackage{iSPlot} and
  \Rpackage{MVCClass}}
\label{Sec:Design}

\subsection{Goals of these new \textsf{R} Packages}\label{Ssec:Goals}

The new \textsf{R} software has three goals: to create views that
are linked, views that are interactive and a design that is
extensible.  Each goal is discussed in more detail in the
following paragraphs.

For the views to be linked, displays based on the same data
must be simultaneously updated when the underlying data change.  As an
example, consider two views where the first view displays height
versus weight and the second view displays age versus cholesterol level.  
Suppose that these four variables (height, weight, age, and
cholesterol level) all come from the same data set and that one
person, John Doe, has his height, weight, age and cholesterol level
stored in the data set.  Now for the views to be linked, certain view
information, such as the color of the data point, whether the point is
hidden or highlighted, and the plotting character of the point, needs
to be stored in a location where all views can access it.  Note that
the view information that needs to be stored in this location
pertains to the visual representation of a data point, which allows
all views that display this data point to render it
in the same fashion.  Information that is not specific to a data point
and instead pertains to the view as a whole is only needed by one view
and does not need to be accessed by other views.  This includes items
such as axis information, background color, margin information, user
coordinates, etc.  To continue the previous example, if the color of John
Doe's data point was originally blue and a request was made to change it
to red (usually through some form of interaction by the user),
then both views need to be updated to reflect the change in
color of John Doe's data point.  Now that point is colored red in
both views, showing that the views are linked.  In other words, both
views are based on shared information about the data and its visual
representation. 

Having interactive views means that when the user interacts with a view,
a response occurs.  Recall from Section \ref{Ssec:Backg} that when
an event occurs, a signal is emitted so an event is a method to tell
an application that something has happened.  Events, such as a button
press or a mouse movement, can then be linked to a callback
function, which determine the response to that event.  The ideas
of events and callback functions are discussed further in Section
\ref{Ssec:RGtk}, which describes the \Rpackage{RGtk} package. 

Suppose that the user clicked on a point in an interactive view.  Here
clicking on the view would generate the event.  In response to this
mouse button press event an action is taken.  In one common scenario,
the nearest point is determined and its color is altered.  In the MVC
paradigm, the callback function would not directly change the points on
the screen, but rather send a message to the model that indicates a
change in color is required.  The model then updates itself and sends
out messages to all subscribed views and the views then respond to
these messages appropriately.  Other possibilities include, but are not
limited to, responding to a key press event generated when the user
presses a key on the keyboard, or a motion notify event when the mouse
moves.  For instance, in response to a motion notify event, an
identifying name could appear next to a point when the cursor rolls
over that point.

Finally, an extensible design is imperative so that future users can
make additions based on their needs.  Thus, the question is how to
create software that can implement linked, interactive plots while
being user-friendly and sufficiently flexible to allow future
additions or revisions.  Given that the software should also allow the
user to perform statistical analyses on the data, the software is
implemented as two \textsf{R} packages, called \Rpackage{iSPlot} and
\Rpackage{MVCClass}.  Therefore, while using this software, the user 
has access to \textsf{R}'s computational and plotting capabilities.  Another
key issue for extensibility is to ensure that users only need to know one
computing language to make additions and for this software, the user only
needs to know how to program in \textsf{R} to make additions.

In Section \ref{Ssec:RGtk}, the use of the \textsf{R} packages, \Rpackage{RGtk}
and \Rpackage{gtkDevice}, for creating interactive views are
explored and in Section \ref{Ssec:MVC}, the design used to created linked
views, which is based on the model-view-controller paradigm, is
discussed. 

\subsection{\Rpackage{RGtk} and \Rpackage{gtkDevice}}\label{Ssec:RGtk}

\Rpackage{RGtk} \cite{RGtk} is an \textsf{R} package that allows one to
interact with Gtk+ functions from the \textsf{R} interface.  Gtk+ \cite{Gtk}
is an open-source window toolkit for creating user interfaces.  Not only is
Gtk+ a particularly rich toolkit that gives the programmer access to many
widgets (user interface components, such as a scroll bar, text box,
button, or drawing area) to quickly build interfaces, but it also
gives access to many events, such as button press events, motion
notify events, delete events.  By exposing the events at this
high level, we can respond to different user interactions in rich
ways.  

In Gtk+, each widget can respond to certain events.  When an event
occurs, the active widget emits a signal.  If the programmer has
defined a callback function for that signal, then the signal is
caught by the signal handler, which calls the callback
function.  Thus, the programmer can decide which events to notice, and
what actions occur in response to those events.  As an example, suppose a
button widget is placed on the interface and 
the programmer has created a callback function for the button
press event for that button.  Let's say that the button has the label,
``Show Plot'', and the callback function for the button press event
causes an X window to open with a plot on it.  Then when the user
presses the button, the callback function is called and a new X
window opens with a plot on it.   

Events are crucial for creating an interactive view since more
available events that can be caught mean more possible interactions
that can be supported.  In the new \textsf{R} software, all views should
respond to certain events, such as delete and button press.  The delete event
occurs when the Gtk+ window containing the view is deleted and thus, storing
information on that view is no longer necessary.  The button
press event allows the user to interact with the view.  For certain
views, the motion notify event also has a callback function so that
the user can identify points by rolling the cursor over the view.  Of
course, these are just some of the possible events and users can
always add callback functions for additional signals if there are events
they want to acknowledge that are currently being ignored.  Also, users can
add multiple callbacks for the same event and each of these callbacks will be
processed in turn.  This allows different actions to be separated into
different callback functions and managed separately.  The
\Rpackage{RGtk} package encapsulates the interface between \textsf{R} and
Gtk+ and users of the new \textsf{R} packages need only be familiar with the
\textsf{R} language to make these additions.

Some of the possible events \cite{Gtk} available for widgets in Gtk+ are:
\begin{list}{}{\setlength{\leftmargin}{0.5in}
               \setlength{\itemsep}{0in}}
  \item \textbf{button press event:} when a mouse button is pressed over a
  widget 
  \item \textbf{button release event:} when a mouse button is released over a
  widget 
  \item \textbf{motion notify event:} when the cursor moves over a widget
  \item \textbf{delete event:} when a widget is deleted
  \item \textbf{expose event:} when a widget is exposed and needs to be
  redrawn
  \item \textbf{key press event:} when a key is pressed and the widget is
  active 
  \item \textbf{key release event:} when a key is released and the widget is
  active 
  \item \textbf{focus in event:} when the widget gets focus 
  \item \textbf{focus out event:} when the widget loses focus
  \item \textbf{drag/drop event:} when a button press occurs on a widget, then
  the button is held down while the mouse is moved, and finally the mouse
  button is released
\end{list}

This list is by no means exhaustive of all events available to widgets
in Gtk+.  For a complete list, please see the list at the URL,
\url{http://www.gtk.org/tutorial1.2/gtk\_tut-28.html}.  Also, specific
widgets may have their own particular events that they can respond to.
For example, a Gtk+ Clist widget, which provides a spreadsheet-like display of
a table of cells, has events such as select row, unselect row, click column,
resize column, etc. Clearly, these events only pertain to a widget with the
appropriate characteristics.   

So far the necessity of events for an interactive view has been
discussed, but the area where these views are displayed
has not been mentioned.  In \textsf{R}, a device is used to display graphics.
There are two basic types of device: screen and file devices.  Screen devices
display the graphics directly on the computer screen; file devices
write the graphics in a format that can be displayed using other
software, e.g. a Web browser, PDF viewer.  Many different types of devices are
available to the user in \textsf{R}, such as postscript, pdf, windows, X11,
jpeg, etc.  For interactive graphics discussed in this
paper, a screen device is needed that looks like one of the regular \textsf{R}
devices, but also makes low-level user events available to the \textsf{R}
programmer.  The package \Rpackage{gtkDevice} \cite{gtkDevice}
provides such a graphics device.  It uses a \texttt{GtkDrawingArea}
widget as a canvas on which to display the \textsf{R} graphics.  It works in
much the same way as other screen devices, allowing the user to create
new top-level windows for graphics, and each window acts as a
container for the drawing widget that is transparently connected to
the \textsf{R} graphics engine.  In addition to top-level windows, a
\texttt{GtkDrawingArea} widget can be located in an arbitrary GUI
(e.g. surrounded by buttons and menus, within a scrolled window, or
even within an HTML document display) and then connected to the
graphics engine and used as a regular graphics device via the function
\Rfunction{asGtkDevice}.  While the \texttt{GtkDrawingArea} plays a
special role in this context of display content from the \textsf{R} graphics
engine, it behaves as a regular Gtk+ widget to the \Rpackage{RGtk}
package.  Therefore, it allows the \textsf{R} programmer to associate callback
functions with different events.  The \Rpackage{gtkDevice} package
therefore gives the \textsf{R} programmer both regular \textsf{R} graphics
and programmable interactive events.

\subsection{Model-View-Controller}\label{Ssec:MVC}

The MVC paradigm \cite{DesignPatterns} is a design that consists of
three types of objects: the controller, which
defines what actions occur in response to user input; the view, which
consists of displays of the data; and the model, which manages the
data.  The power of the MVC design is that it decouples the views of
the model from the model itself by creating a subscribe/notify procedure
between them.  In other words, the views subscribe to a particular
model and the model must notify the views when a change occurs so that
the views are updated.  This allows multiple views of the model
that are linked, but are not aware of each other.  And similarly, the model
has no particular knowledge of any of the views, just how to notify them of
changes to the contents of the model.

Figure \ref{Fig:ModelV} from \cite{DesignPatterns} gives an example of a model
(on the second row) with several views (on the first row) based on that model.
The model data consist of a labeled vector of numbers data that are reflected
in the views.  When the model changes, it must notify the views so that the
views reflect the current data.  Once the views have been notified of a change
in the model, then the views can ask the model for information.  By separating
the model from its views, only one copy of the model needs to be stored.

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.8}{\includegraphics{ExMVC.jpg}}
    \caption{ Model with its views. }
    \label{Fig:ModelV}
  \end{center}
\end{figure}

The views must know which model they are displaying, but the model
does not need to know about the views.  If the model changes,
it needs to notify the views in some manner that it has
changed.  This communication between components in a \Robject{MVC} object is
discussed in detail in Section \ref{Sssec:Message}. 

Not only does there need to be communication between the views and the
model, but there must also be information passed between the
controller and the views.  Recall that the controller defines what
actions occur in response to user input.  If the user input is
interaction with a view, the controller must query the view in order
to determine which component was selected.  For example, a mouse click
event typically only provides the $(x,y)$ coordinates of the cursor at
the time the mouse was clicked.  To identify the nearest point the
callback function must query the view.  When the user clicks a point
on a view, the controller responds to this event by asking the view
which point was nearest.  Then the controller tells the model that it
should be updated. The model data are updated and all views notified.
Note, that typically the callback function does not directly modify
the view.

There are exceptions to this rule, and one common situation is when
the controller itself has an on-screen representation.  For example, a
histogram might have associated with it a slider to represent the
number of bins to use.  When the user moves the slider the new
information must be stored somewhere, and the view updated.  There are
two different ways this can be addressed.  One is where the model is
sufficiently rich so that it holds such information and in that case
the behavior is much as we described above.  But an equally valid
implementation would store such information with the view, since it is
unlikely to be of any interest to other views and could vastly
complicate the model (this is in fact our design choice). 

In our system there is a mechanism that allows the user to change the
response associated with an event, for any of the views.  Users are
able to change the response to the mouse button click event, so
sometimes it hides points, other times it colors them, and other times
pops up glyphs or other graphical objects.  In our design this
corresponds to being able to alter the controller, but one could also
imagine an implementation where such data were part of the model,
although again that may complicate the model, and we feel that makes
the roles of model and controller ambiguous.

Figure \ref{Fig:MVC} shows a visual representation of the MVC design.  As
shown in this representation, communication is possible between any of the
components of the design.  For instance, the model may send information
to the view or the view may send information to the model.  

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.7}{\includegraphics{MVC.jpg}}
    \caption{ MVC design. }
    \label{Fig:MVC}
  \end{center}
\end{figure}

For extensibility, it is crucial to have the design consist of
separate components with communication mechanisms so that if one component
changes, it does not
affect the other components.  By using the MVC paradigm
with messages to communicate between components, the components
are compartmentalized.  Thus, if a user wants to change one piece, such
as the model layer, only that component needs to change and
possibly the messages that are sent and received from that component.
However, the other two components should not be affected.  The changes to the
model must of course leave unchanged the programming interface that the other
components use to communicate with that model. 

\subsection{Overview of \Rpackage{iSPlot} and \Rpackage{MVCClass}}\label{Ssec:Overview}

First, it is necessary to differentiate between the goals of these two
\textsf{R} packages and how they come together to fulfill the goals described
in Section \ref{Ssec:Goals} for the overall software.  These goals were to
create views that are linked, views that are interactive, and a design that is
extensible. 

To create linked views, the MVC paradigm was discussed in
Section \ref{Ssec:MVC}.  This paradigm is the basis of the new \textsf{R}
package, \Rpackage{MVCClass}.  The \Rpackage{MVCClass} package creates class
definitions and generic functions to implement the MVC
design.  By separating these definitions into their own \textsf{R} package,
these components can be used by any other package that creates linked
views. 

Next, to create interactive views, a front end that creates these views is
necessary and that is performed by the new \textsf{R} package,
\Rpackage{iSPlot}.  The \Rpackage{iSPlot} package lets the user create views
that are interactive through either command line functions or through a GUI.
These interactive views are linked to each other via the underlying
data set, or model, by creating objects from the model, view and MVC
classes defined in the \Rpackage{MVCClass} package.  A detailed
discussion of these classes is given in Section \ref{Ssec:Details}.
The \Rpackage{iSPlot} package determines how objects of a class act by
defining the methods for the classes. 

As far as extensibility, both packages, \Rpackage{MVCClass} and
\Rpackage{iSPlot}, are intended to be extensible.  If the user wants to add a
new class or a new generic function, this can be done by extending the
definitions in the \Rpackage{MVCClass} package (i.e. by inheriting from
classes already defined in \Rpackage{MVCClass}), and if the user wants to add
a new menu to the GUI, this can be done using command line functions available
from the \Rpackage{iSPlot} package.  Examples of the functionality defined in
the packages are given in Sections \ref{Ssec:Details} and \ref{Sec:Func}, but
basically a user can think of the \Rpackage{MVCClass} package as the back end,
which defines classes and generic functions, and the \Rpackage{iSPlot}
package as the front end, which creates the views and defines the
responses to user interactions through either a GUI or command line
functions.

\subsubsection{Overview of \Rpackage{MVCClass} Design}\label{Sssec:OverMVC}

Prior to explaining the details of the \Rpackage{MVCClass} design, a short
overview of design decisions for the MVC paradigm is
explained here and then in Section \ref{Ssec:Details} a more in-depth
discussion of the design is given.

The controller must perform several tasks, including storing
information about the state of the \Robject{MVC} entity (such as how
to respond to user interaction with a view) and allowing users to
load data, to create views, and to quit the program.  These tasks can
be separated into two functions: i) the controller stores MVC state
information, ii) the controller provides some form of interactive
interface that allows the user to determine the course of actions. MVC
state information is stored in the \Rslot{controller} slot of a
\Robject{MVC} instance (Section \ref{Sssec:MVC}).  The implementation
of ii) is contained in the \Rpackage{iSPlot} package, because this
package lets the user determine the course of actions through either
command line functions or the GUI.

In the MVC paradigm, the model component is the place where data
are stored and updated.  Thus, the model is basically a storage
location with certain operations, such as loading and updating the model data,
defined for it.  Information can be sent to
the model to add, update and remove data and the model can send out
messages that changes have occurred to the data.  The details of the
model component design are given in Section \ref{Sssec:Model}.

The views consist of different ways of representing the data
visually.  Even though there are different ways to view the data,
such as via a scatter plot or a spreadsheet, each view needs to store
information and needs to respond to events, such as a mouse button
click.  This observation suggests an object model where
different view classes inherit from a common virtual class.
This implementation ensures that all views store common information in a
standard way and respond to certain events without the need to write
specialized methods.  Views that require specialized responses require the
implementation of specialized methods, but the virtual class ensures that they
all make use of the standard methods if they are appropriate.  The object
model for views is discussed in Section \ref{Sssec:View}.

These three components -- model, view, and controller --of the MVC design are
tied together in one class, called \Rclass{singleModelMVC}.  Each object of
class \Robject{singleModelMVC} contains one data set (the model) and the
\Robject{singleModelMVC} object contains all the information pertaining to
that particular model.  More details on this class can be found in Section
\ref{Sssec:MVC}. 

Communication between the three objects in the MVC design is crucial
for the pieces to work together and yet, still be independent of each
other.  To perform communication between the three components, message
classes were created in \Rpackage{MVCClass}.  Just as with the view
classes, there are different types of messages, such as update or add,
and they inherit from a common virtual class, which 
ensures that all messages store some common information and have
methods in common.  A detailed discussion of the message classes
is given in Section \ref{Sssec:Message}.   

Finally, a class called \Rclass{gEventFun} is also defined in the
\Rpackage{MVCClass} package.  This class contains all the necessary
information for a callback function, which can then be linked to an event (see
Section \ref{Ssec:Backg} for more information on events and callback
functions).  More information on this class is given in Section
\ref{Sssec:Event}. 

\subsubsection{Overview of \Rpackage{iSPlot} Design}\label{Sssec:OveriSPlot}

A short description of the design decisions for the \Rpackage{iSPlot} package
is given here.  More details of the \Rpackage{iSPlot} package are given in
Section \ref{Ssec:Details}. 

The \Rpackage{iSPlot} package gives the user access to the application program
interface (API) either through a GUI or through command line functions.  Thus,
the \Rpackage{iSPlot} package fulfills one of the goals of the controller,
mentioned in Section \ref{Sssec:OverMVC}, which is to allow the user to
determine the course of actions.  For the GUI, a design that users are
familiar with from using Windows software is to have menus that allow the user
to determine which action to take next.  In the \Rpackage{iSPlot} package's
implementation, the GUI is created using the \Rpackage{RGtk} package, which
was discussed in Section \ref{Ssec:RGtk}.  For users that do not want to use
the GUI, the same functionality is available through command line functions.
More information on the controller and thus, on the API is given in Section
\ref{Sssec:Control}. 

Since the \Rpackage{iSPlot} package creates the front end, decisions made in
this package pertain to what types of data are allowed and what
operations can be performed on these data sets and their views.  Of course,
since one of the goals of this software is to be extensible, the user is
welcome to make additions to the available operations.  A more detailed
discussion of what is currently possible through the \Rpackage{iSPlot}
package's front end is given in Sections \ref{Ssec:Details} and \ref{Sec:Func}.

\subsection{Details of the Design}\label{Ssec:Details}

This section intertwines the details of the design of the
\Rpackage{MVCClass} and the \Rpackage{iSPlot} packages because the packages
work together to satisfy the goals of this software.  All of the classes
and generic functions are defined in the \Rpackage{MVCClass} package, and the
methods and the API are implemented in the \Rpackage{iSPlot} package.

Note that the \Rpackage{MVCClass} package is designed to be a back end for any
package that wants to use the model-view-controller paradigm.  Thus, there are
more classes and generic functions defined in the \Rpackage{MVCClass} package
than are used in the \Rpackage{iSPlot} package.  Only classes and generic
functions that are used in the \Rpackage{iSPlot} package are discussed
here.

\subsubsection{Model}\label{Sssec:Model}

In Section \ref{Sssec:OverMVC}, the model layer is explained to be a storage
location where data can be added, updated, or removed.  Thus, the model class
reflects those operations.  The functions of storing and updating
the data are reflected in Figure \ref{Fig:Model}, which shows the inheritance
structure for the model classes.  Here the virtual class, \Rclass{gModel},
has the slots \Rslot{modelData}, \Rslot{linkData}, \Rslot{virtualData}, 
\Rslot{modelName}, and \Rslot{modelVar}.  These five slots are common
information that all models need.  The \Rslot{modelData} slot is the data set
for this model; the \Rslot{linkData} slot is used to link this model to other
models (this feature is not used in this software so it is left as an empty
slot); the \Rslot{virtualData} slot is data pertaining to the views that need
to be stored with the model so that it can be shown in all views of this
model; the \Rslot{modelName} slot is the name of the model; and
\Rslot{modelVar} is a list of any model variables, which are extra data that
are stored with the model, such as test statistics calculated from the model
data.  

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.7}{\includegraphics{ModelClass.jpg}}
    \caption{ Inheritance for model classes. }
    \label{Fig:Model}
  \end{center}
\end{figure}

As for specific model classes, the only class used by the \Rpackage{iSPlot}
package is \Rclass{dfModel}.  Other model classes are defined in the
\Rpackage{MVCClass} package, but this software currently intends only to look
at linking views of two-dimensional data structures, such as a data frame or a
matrix.  The \Rclass{dfModel} class represents a model where the
\Rslot{modelData} slot has class data frame (or matrix).
 
The model class is also responsible for updating the data so a method for the
generic function, \Rfunction{updateModel}, is needed by the \Rclass{dfModel}
class.  The generic function is defined in the \Rpackage{MVCClass} package and
the method is defined in the \Rpackage{iSPlot} package.  This method is called
whenever the data need to be updated in response to a user interaction with a
view.  All view specific information is stored in the \Rslot{virtualData}
slot.  This includes color of point, glyph used, and other variables.  These
are held separate from the model data itself, partly for efficiency purposes
and partly to avoid name conflicts.  Often the \Rfunction{updateModel}
method is actually updating the \Rslot{virtualData} slot because these
data control the coloring, etc.  This is an important and potentially
slightly subtle point.  The data are often essentially considered
fixed/immutable.
  
Note that the model classes also must notify views when the data have changed
so that the views can be updated.  The communication between a model and its
views is discussed in Section \ref{Sssec:Message}.

If a user wants this software to create linked, interactive views of different
data structures, then she will need to add a new model class.  For
example, a user may want to add a new model class called, say,
\Rclass{tsModel} to represent time series data and define methods for
the different generic functions to implement the way updates work for
this particular model.  Some examples of such extensions are available
in the \Rpackage{iSNetwork} package, which provides a different set of
extensions of the MVC paradigm.
  
\subsubsection{Views}\label{Sssec:View}

As mentioned in Section \ref{Sssec:OverMVC}, although there are
different views of the data, all views should store some common
information and respond to certain events through methods.  This led to
an object model where the different view classes inherit from a view
virtual class, called \Rclass{genView}.  These classes are defined in the
\Rpackage{MVCClass} package.  A design of the view classes that fits the
representation of the views and allows for extensibility is shown in
Figure \ref{Fig:View}.  The design is discussed in the following
paragraphs. 

\begin{figure}[!h]
  \begin{center}    
    \scalebox{.70}{\includegraphics{ViewClass2.jpg}}
    \caption{ Inheritance for view classes. }
    \label{Fig:View}
  \end{center}
\end{figure}

The \Rclass{genView} class is a virtual class that has three slots,
\Rslot{dataName}, \Rslot{win}, and \Rslot{winNum}.  \Rslot{dataName} is the
name of the model that the view displays, \Rslot{win} is the Gtk+ window object
that holds the view, and \Rslot{winNum} is the number of the window so that
the window can be identified in the Window menu on the GUI (see Section
\ref{Sssec:Control}).  All views need to know these three pieces of
information so \Rclass{genView} binds the different view classes together. 

As for specific view classes, the \Rclass{spreadView} class represents a
spreadsheet view of the data.  The additional information needed for this view
is stored in the slot, \Rslot{clist}, which is the Gtk+ spreadsheet object. 

When plotting the data, there is a general class, \Rclass{plotView}, that has
the slots, \Rslot{drArea}, \Rslot{plotDevice} and \Rslot{plotPar}, which store
the Gtk+ drawing area object, the \textsf{R} graphics device number (which
uniquely identifies the device to \textsf{R}) of the plot, and the plotting
parameters, respectively.  The \Rclass{sPlotView} class represents a scatter
plot view of the data.  The extra information needed for this view
(that is not already contained in \Rclass{genView} and \Rclass{plotView}) is
stored in the three slots -- \Rslot{dfRows}, \Rslot{xvar} and \Rslot{yvar} --
where \Rslot{dfRows} are the model row names, \Rslot{xvar} is the variable
name from the model that is shown as the ``X'' or horizontal axis variable in
the plot, and \Rslot{yvar} is the variable name from the model that is shown
as the ``Y'' variable, i.e. on the vertical axis, in the plot. 

These four view classes (\Rclass{genView}, \Rclass{spreadView},
\Rclass{plotView}, and \Rclass{sPlotView}) are defined in the
\Rpackage{MVCClass} package.  The \Rpackage{MVCClass} package also has other
view classes that are defined, but these views represent displays of data
structures that are not currently used in the \Rpackage{iSPlot} package.

Since all views are expected to be interactive, all view classes have methods
that correspond to user interaction.  At any one time at most one view has the
focus and if an event occurs, the view that has focus will react according to
the controller that is active for that view.  The events we are most
interested in responding to include key press
events, where a certain configuration of keys are pressed; button click
events, where one of the mouse buttons is clicked over the view; and mouse
movement events, where the cursor moves over the view.  Recall from Section
\ref{Ssec:Backg} that when an event occurs Gtk+ emits a signal that is caught
by the signal handler.  The signal handler then calls the callback function
and it is in the callback function that the corresponding method is called.

For example, in the code below, \Rfunction{gtkAddCallback} is the signal
handler and it connects the button press event on the drawing area of a view
with the callback function, which is the unnamed function, with the signature:
function(obj, ev).  In the callback function, the \Rfunction{clickEvent}
method for the current view is called.  The signature for the scatter plot's
\Rfunction{clickEvent} method is shown directly below.  Using the information
that is passed to the \Rfunction{clickEvent} method in the \Rslot{where}
parameter, the method converts the Gtk+ pixel coordinates that indicate where
the event occurred into user coordinates and then into an object from the
plot, such as a point on the plot.

\begin{verbatim}
gtkAddCallback(drArea(curView), "button_press_event",
  function(obj, ev)
  {
    clickEvent(curView, ev)
    return(TRUE)
  }
)

setMethod("clickEvent", "sPlotView", 
  function(object, where, ...) 
  {}
)

\end{verbatim}

Currently, both \Robject{spreadView} and \Robject{sPlotView} respond to button
press events, while only \Robject{sPlotView} responds to a
motion notify event (when the cursor rolls over the view).  However, linking a
response to the motion notify event for \Robject{spreadView} can be
accomplished by performing the following two steps: i) adding a Gtk+ callback
for the motion notify event to the \Rfunction{initialize} method for
\Robject{spreadView} and ii) defining the \Rfunction{motionEvent}
method for \Robject{spreadView}.

For \Robject{spreadView}, which is a spreadsheet, the
\Rfunction{clickEvent} method is called when Gtk+ emits a signal
that a row has been selected or unselected.  For \Robject{sPlotView},
which is a scatter plot, the \Rfunction{clickEvent} method is called
when Gtk+ emits a signal that a mouse button has been pressed and the
\Rfunction{motionEvent} method is called when Gtk+ emits a signal that
the cursor has been moved over a view.  Both the \Rfunction{clickEvent} and
\Rfunction{motionEvent} methods for a \Robject{sPlotView} object
determine which point on the plot was clicked or under the cursor,
respectively.  For more information about the \Robject{sPlotView's}
\Rfunction{clickEvent} method, please see the Appendix, which contains a
section called Example Event.  This section explains the steps that happen
when a mouse button press event occurs on a scatter plot. 

As with the model classes, each view class needs a method that tells an
instance to update its display.  This is the \Rfunction{updateView} generic
function, and a method is defined for each view class.  This method must take
the information that a model has just been updated and appropriately update the
view to reflect that change.  Each \Rfunction{updateView}
method depends on how the view represents the data so for a
\Robject{spreadView} object the \Rfunction{updateView} method may select or
unselect a row on the spreadsheet, while for a \Robject{sPlotView} object the
\Rfunction{updateView} method may change the appearance of a point on the
plot.  Notice that this method would ideally only redraw
the relevant portion of the view to reflect the change in the data in
the interest of efficiency and minimizing visual impact.  For certain
views, this may not be possible, and a view may need to update its
entire display.  Indeed, the view classes also should be able to
completely redraw the view rather than just updating a portion of the
view, and it is sometimes necessary for the software to be able to
instruct one or more views to do this.  Thus, all views have a
\Rfunction{redrawView} method.  Both the \Rfunction{updateView} and
\Rfunction{redrawView} methods are called by the \Rfunction{handleMessage}
method of a \Robject{gUpdateViewMessage}, which is created after the model is
updated.  Message classes are discussed in Section \ref{Sssec:Message}. 

The design of the view class hierarchy and inheritance structure is
intended to facilitate extensibility.  For instance, if users wanted
to add a new plot view, say a density plot, they could create a new
view class that inherits from \Rclass{plotView}, called say
\Rclass{dPlotView}.  This new class, \Rclass{dPlotView}, has slots
named \Rslot{dfRows} and \Rslot{var} to store which rows and which
variable, respectively, were used to calculate the density shown in
the view.  Alternatively, one could elect to extend \Rclass{sPlotView}
if the characteristics of the new view were more like a scatter plot,
and the inherited methods were sensible.  In this case, the new class
would inherit the \Rslot{dfRows} slot, and could make use of the
\Rslot{xvar}, and ignore the inherited \Rslot{yvar}.  Whether this is
a good design choice depends on the complete set of characteristics of
the three classes - \Rclass{plotView}, \Rclass{sPlotView} and
\Rclass{dPlotView}.

\subsubsection{Controller}\label{Sssec:Control}

Recall that the controller performs two tasks: i) store information on
state, and ii) provide an interactive interface that allows the user to
determine the course of actions.  In Section \ref{Sssec:OverMVC}, it
was also mentioned that the first task is implemented via classes and
methods in the \Rpackage{MVCClass} package and the second is
implemented in the \Rpackage{iSPlot} package.

For the first task of storing information we make use of
\Robject{environments}, which are \textsf{R} data structures that contain
key-value pairs, but for which the usual copying semantics do not
apply.  Hence, \Robject{environments} provide an efficient and natural
mechanism for storing state information and provide functionality that is
similar to references in other languages. This data structure is stored in the
\Rslot{controller} slot of an \Robject{MVC} instance.  This
\Robject{environment} stores data such as information about the appearance of
the views for that particular \Robject{MVC} entity.  

For the second task, which is implemented in the \Rpackage{iSPlot}
package, the controller gives the user access to the API, either through the
GUI or through command line functions.  Through the API the user can load
data, create views, set the response to user interaction with a view, quit the
program, and perform other functions.  On the GUI, there are menus to let users
decide which action is taken next.  If the user would rather not use the GUI,
there are command line functions that provide access to the same functionality
that is available through the GUI.  The GUI is shown in Figure
\ref{Fig:Control} and is referred to as the control window.

\begin{figure}[!h]
  \begin{center}    
    \scalebox{.50}{\includegraphics{ControlWindow.jpg}}
    \caption{ The \Rpackage{iSPlot} controller (the control window). }
    \label{Fig:Control}
  \end{center}
\end{figure}

As shown in Figure \ref{Fig:Control}, the menus on the control window are
File, Edit, Display, Event, and Window.  These menus always appear on the
control window.  Because more than one model can be loaded, the
concept of the \textit{active} model is implemented in the \Rpackage{iSPlot}
package.  Being the \textit{active} model means that operations performed
through the control window menus (or through the command line functions) only
affect that model and its views and its controller.  Thus, the \textit{active}
model is the same as the \textit{active} \Robject{MVC} since
each \Robject{MVC} entity can only have one model.  Thus, the \textit{active}
model is also referred to as the \textit{active} \Robject{MVC}.  More details
on the \Rclass{MVC} class are given in Section \ref{Sssec:MVC}.  For example,
if the user has two models (Model 1 and Model 2) loaded, but the
\textit{active} model is Model 1, then only views of Model 1 can be created
through the control window menus (or command line functions) because it is the
\textit{active} model. 

Because interacting with the views should be driven by the user,
the Event menu allows the user to determine what response occurs when
there is user interaction with a view.  For example, the user may initially
want a point on a plot to be colored when the left button is pressed and
the cursor is over that point.  Then the user may decide that the point
should be hidden when the left button is pressed and the cursor is over that
point.  The Event menu lets the user decide if anything happens in
response to a left button click, a middle button click, a right button click,
and mouse movement.  More information is given in Section
\ref{Sssec:Event} about linking an event with a callback function so that user
interaction with a view is flexible enough to allow for multiple outcomes.

Since extensibility is a key concern with the design of \Rpackage{iSPlot},
users are able to add menus and menu items to the control window through the
command line.  As an example, if a programmer wants to add a new type
of view, such as a histogram, then a new menu item to create instances of that
view could be added to the Display menu.  The steps for adding a histogram
view to \Rpackage{iSPlot} are shown in the Use Case in Section
\ref{Sssec:Extens}.  By allowing users to change the control window, they
can add new functionality that is specific to their problem. 

\subsubsection{Linking Events to Functions}\label{Sssec:Event}

Linking callback functions to events, such as a button click, a mouse movement
or a key press event, is what allows users to have an interactive graphics
environment.  When an event occurs, the callback function linked to the event
determines the response to that event.  To create a flexible environment it 
should be possible to change the response, which is determined by the callback
function, to an event.  For example, when a left button press event
occurs, a user may sometimes want a point to be colored and at other times she
may want a point to be hidden.  In order to simplify programming for
end-users, it is desirable to be able to replace one callback (e.g. change
color) with another callback (e.g. hide point) dynamically.  Otherwise, all
potential actions would have to be encoded in a single fixed callback
and that single function would need to consult a state variable to
determine which action to take in response to an event. 

To allow this flexibility in the response to an event, a class called
\Rclass{gEventFun} was created in the \Rpackage{MVCClass} package.  The
\Rclass{gEventFun} class stores all of the information needed to respond to
a particular event.  Clearly, the response to an event can be
performed by a single function, which is called the callback function, as
discussed in Section \ref{Ssec:Backg}.  However, different responses to an
event may require functions with different signatures, where a function
signature is the combination of the function name along with its parameters.  
Using the example in the previous paragraph, a callback function that colored
a point needs two parameters, the new color to use and the point to color,
while a callback function that hid a point needs just one parameter, the point
to hide.  Since the intention is to be able to interchange the responses to an
event, the signatures of different callback functions should be the same.
These design decisions determined the slots in the \Rclass{gEventFun} class
and are discussed more fully in the following paragraphs. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{EventClass.jpg}}
    \caption{ The gEventFun class. }
    \label{Fig:EventFun}
  \end{center}
\end{figure}

As shown in Figure \ref{Fig:EventFun}, the slots in the \Robject{gEventFun}
class are \Rslot{callFun}, \Rslot{shortName}, and \Rslot{preprocessFun}.  The
\Rslot{callFun} slot is the callback function, the \Rslot{shortName} slot is a
short description of the function that identifies the callback function, and
the \Rslot{preprocessFun} slot is a list of all
preprocessing functions that must be called before the callback function.

The callback function that is stored in the \Rslot{callFun} slot must take
only one required argument.  As discussed previously, all callback functions
must have the same signature so that different callback functions can be
interchanged in the code to allow different responses to an event.  All
callback functions need to know what object they should act on so this is the
one parameter that the callback functions take.  For instance, for a data
frame model, the parameter is of class \Rclass{character}, representing a row
in the data frame.  Any other information a callback function may need is set
using the preprocessing functions. 

The preprocessing functions that are stored in the \Rslot{preprocessFun} slot
take no parameters.  The purpose of the preprocessing functions is to set
variables that the callback function needs.  Thus, not all callback
functions need preprocessing functions and if no preprocessing functions
are needed, then this slot is NULL.  If the callback function sets the
color of a point in a scatter plot, then a preprocessing function is needed to
determine what color is used.  Thus, in this example, the preprocessing
function opens a color browser to allow the user to choose what the new
color is.

When a user wants to link a callback function stored in a \Robject{gEventFun}
instance to an event, this can be performed either through the Event menu on
the GUI or through the command line functions.  The controller environment in
each \Robject{MVC} object, which is discussed in Section
\ref{Sssec:MVC}, stores which \Robject{gEventFun} object (representing the
callback function) is linked with each event.  Not all callback
functions make sense for each event so the controller environment also stores
a list for each event of appropriate \Robject{gEventFun} instances that can be
linked to that event.

\subsubsection{MVC}\label{Sssec:MVC}

The \Robject{MVC} class binds the model, view, and
controller objects into one object.  Thus, whenever a new data set is loaded,
a \Robject{MVC} object is created.  The loaded \Robject{MVC} objects are
stored in an environment, called \Robject{mvcEnv}, which is discussed in more
detail in the Appendix.  A
\Robject{MVC} object can have one model and each model must be in one
\Robject{MVC} object so there is a one-to-one relationship between the
\Robject{MVC} and model objects.  Because of this relationship, the
\Robject{MVC} object and the model object are identified by the same name,
which is stored in the \Rslot{modelName} slot of the model object.  To load a
new model, the name of the model must be unique from all the previously loaded
models.  If it is not unique, the new data set is not loaded.

As shown in Figure \ref{Fig:MVCClass}, there is a virtual class, \Rclass{MVC},
that binds the MVC inheritance structure together.  This virtual class,
\Rclass{MVC}, has three slots, which are \Rslot{model}, \Rslot{viewList}, and
\Rslot{controller}.  The \Rslot{model} slot stores
the model object, the \Rslot{viewList} slot is a list of the view
objects for this model, and the \Rslot{controller} slot is an environment that
stores information for this \Robject{MVC}.  These three pieces of information
are needed to bind the model, view and controller into one object.  To create
instances of \Robject{MVCs}, the \Rclass{singleModelMVC} class, which inherits
from the virtual \Rclass{MVC} class, can be used.  

\begin{figure}[ht]
  \begin{center}
    \includegraphics[height=2.2in, width=1.2in]{partMVCClass.jpg}
    \caption{ Inheritance for \Robject{MVC} classes. }
    \label{Fig:MVCClass}
  \end{center}
\end{figure}

\subsubsection{Messages}\label{Sssec:Message}

Whenever the components need to communicate with one another, a
message object is sent as discussed in Section \ref{Sssec:OverMVC}.  
This communication between the model, view and controller is crucial for the
pieces to work together and yet, still be independent of each other.  

The processing of messages in this MVC-style software is handled
centrally and generally.  It is important that
all messages have a common set of basic methods, such as
\Rfunction{initialize} and \Rfunction{handleMessage} so that this
central processing could work on any message without having to know
anything about its details.  All messages are sent to the
\Rfunction{handleMessage} method which determines where the
information should be sent, and hence is the dispatcher.  These
generic functions facilitate the introduction of new message classes
in new software without the programmer having to modify this software.

Since messages are sent when something has changed, either through
addition, alteration, or deletion, each message class reflects the
specific change/operation.  These common operations for the messages
allow the message object model to be constructed, and this model is
shown in Figure \ref{Fig:Message}.

\begin{figure}[!h]
  \begin{center}    
    \scalebox{.70}{\includegraphics{newMessageClass.jpg}}
    \caption{ Inheritance for message classes. }
    \label{Fig:Message}
  \end{center}
\end{figure}

As with the view classes, the top message class, \Rclass{gMessage},
is a virtual class.  It contains no slots and its purpose is to provide a
common node in the class hierarchy for the purpose of facilitating
extensibility and defining default methods for generic functions.

Currently, there are two types of messages for communicating within a
model, view, controller object: an add and an update message.  These two types
of messages are both performing some type of modification and thus, both the
add message, \Rclass{gAddMessage}, and the update message,
\Rclass{gUpdateMessage}, inherit from the virtual class,
\Rclass{gModifyMessage}, which contains three slots, \Rslot{dataName},
\Rslot{mData}, and \Rslot{type}.  \Rslot{dataName} is the character string
that gives the name of the model, \Rslot{mData} is a list of data needed to
perform the addition or alteration operation, and \Rslot{type} is a character
string that gives the type of addition or alteration to perform.  Both
\Rclass{gAddMessage} and \Rclass{gUpdateMessage} are virtual classes.

Since adding a view requires different information and methods from adding a
model (and similarly with updating views versus models), it makes sense to
have two separate classes for these different types of elements.  Messages
sent between the model, view, and controller components are from one of the
following classes: \Rclass{gAddViewMessage}, \Rclass{gAddDataMessage},
\Rclass{gUpdateViewMessage}, and \Rclass{gUpdateDataMessage}.  The
\Rclass{gAddDataMessage} class represents a message to add a model and a
\Robject{MVC} object because whenever a model is added, a \Robject{MVC} object
is created that contains this model.  The \Rclass{gAddViewMessage} class
represents a message to create a view.  This type of message can only be used
after a model has been added. 

The \Rclass{gUpdateDataMessage} class represents a message to update
a model.  This message is crucial for linking because it is responsible for
ensuring that once a model has been updated, this information propagates to
all views of the model.  The \Rslot{from} slot in the
\Robject{gUpdateDataMessage} object indicates which model sent this
message.  This slot is needed when models are linked because an update data
message may come from either a different model or from a view of this model.
Model linking is a feature that is not implemented in the \Rpackage{iSPlot}
package so this slot always reflects that the update data message came
from a view within the \Robject{MVC} object.  In the \Rpackage{iSPlot}
package views can be linked because they are based on the same model, but
models can not be linked.  

Finally, the \Rclass{gUpdateViewMessage} class
represents a message to update a view.  This message is created and handled
whenever the model is updated so that the views accurately reflect the model.

An example of message passing within a \Robject{MVC} object is shown
in Figure \ref{Fig:MPwithin}.  In this example, there are two views of the
model (View 1 and View 2), and the response to a user
performing a button click event over a point in the scatter plot is to
color the point red.  Setting the response to an event was discussed
in Section \ref{Sssec:Event}.  Here the user first clicks on a point
in View 1, which is shown as Step 1 (the circled 1 on the
figure).  In the figure, the point that has been clicked has an arrow
next to it.  Then, in Step 2, an update data message is sent to the
model, which updates itself accordingly, i.e. by changing the color
associated with the corresponding element in the \Rslot{virtualData} slot of
the model object.  After the model has been
updated, the views must be notified that a change has occurred so in
Step 3, an update view message is created and sent to all views of
this model.  In response to this message, the views update themselves in
Step 4 and now each view has one point that is colored red to reflect the
change in the model.  In this example, the \Rslot{from} slot in the
\Robject{gUpdateDataMessage} object is the name of this \Robject{MVC} object
since the message came from within the \Robject{MVC}. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{newMPwithin2.jpg}}
    \caption{ Message passing within a \Robject{MVC} object.  The first step,
      indicated by a circled one, occurs when a user interacts with the y
      versus x scatter plot (View 1).  Then an update data message is sent to
      the model in the second step, which alters the model.  Next in the third
      step all views of this model are sent an update view message, which
      causes the views to be updated in the fourth step. }
    \label{Fig:MPwithin}
  \end{center}
\end{figure}

All four classes, \Rclass{gAddDataMessage}, \Rclass{gAddViewMessage},
\Rclass{gUpdateDataMessage}, and \Rclass{gUpdateViewMessage}, have
\Rfunction{initialize} and \Rfunction{handleMessage} methods, which perform
the following tasks.  The \Rfunction{initialize} method is used to properly
fill the slots of the object when it is created.  The
\Rfunction{handleMessage} method is necessary to process the message.  Since a
message is a form of communication between two components, once it is created
it must be sent to the proper recipient and action must be taken in response
to its information, which is the purpose of the \Rfunction{handleMessage}
method. 

As with the inheritance structures seen in previous sections, the message
inheritance structure is designed to allow for extensibility.  For example, a
user could create a \Rclass{gUpdateControlMessage} class that inherited from
the \Rclass{gUpdateMessage} class.  This new class,
\Rclass{gUpdateControlMessage}, could convey information that told the
control window to be updated in response to a change in the active view (the
active view is the view that has focus).  Currently, the control window does
not reflect what the active view is, but if a view was created whose axes
could be rotated to provide a different perspective on the data,
then a user may want the control window to have some type of
interface to allow control of the rotation.  The goal for the message classes
is that the design is flexible enough to allow a user to make additions or
changes. 

\subsubsection{Extensibility in Overall Design}\label{Sssec:Extens}

Not only was the overall design using model-view-controller planned to
promote and facilitate extensibility, but within each component, the goal has
been to 
create a flexible design so that users can easily make changes or
additions.  For the controller, new menus and menu items can be
created and added to the control window, giving the user the ability to create
new actions for the system.  For the model, new model classes can be added for
new data structures.  For the views, new view classes can be created that
inherit from the existing view classes, giving the user the ability to create
new displays that may be applicable to their data.  Similarly, for the
messages, new message classes can be created that inherit from the
existing message classes.  Messages are particularly important in their
role of communicating between components since they allow the components to
remain unaware of each others existence.  Also, to make
extending the design easier for the user, all additions can be made in the
\textsf{R} language.  

Developers can also extend the available options for a response to an event.
This extension can be performed by creating a new \Robject{gEventFun} object to
represent a callback function.  More details are given in Section
\ref{Ssec:EventMenu} about how to perform this extension. 
As an example of an addition that a user may want to make, the
following Use Case describes the general steps needed to add a
histogram view to \Rpackage{iSPlot}.  For a reference on Use Cases,
please see \cite{UseCase}.

\textbf{Use Case for Adding a Histogram}

\textbf{Primary Actor:} Programmer
\newline
\textbf{Scope:} \Rpackage{iSPlot} and \Rpackage{MVCClass} Package
\newline
\textbf{Level:} Summary
\newline
\textbf{Stakeholders and Interests:} Users of \Rpackage{iSPlot}
\newline
\textbf{Precondition:} Programmer has access to the \Rpackage{iSPlot} and
\Rpackage{MVCClass} code
\newline
\textbf{Success Guarantee:} A new histogram view, which is an
interactive and linked view, is available to users.
\newline
\textbf{Main Success Scenario:}
\newcounter{spacerule}
\begin{list}{\textbf{\arabic{spacerule}. }}
              {\setlength{\leftmargin}{0.5in}
               \setlength{\itemsep}{0in}
               \usecounter{spacerule}}
  \item Programmer adds a new menu item to the Display menu on the
               control window in the \Rpackage{iSPlot} package.  This menu
               item allows a user to create a histogram view.
  \item Programmer creates a function that is called when the
  menu item (created in step one) is activated.  This function
  allows the user to choose which variable to plot and then
  creates the histogram with the appropriate data from the \textit{active}
  model.  
  \item Programmer creates a new view class that represents a
  histogram view and that inherits from one or more classes in the
  \Rpackage{MVCClass} package.  This new view class needs to store
  information, such as the column and rows that were used to create the
  histogram.  
  \item Programmer must define methods for the new histogram view class in the
  \Rpackage{iSPlot} package and these methods must include an
  \Rfunction{initialize}, an \Rfunction{updateView} and a
  \Rfunction{redrawView} method.  The \Rfunction{initialize} method properly
  sets up the view, creates the view instance, and makes sure that the view can
  respond to certain events, such as key press, delete, focus in, and button
  clicks (see the next step).  The \Rfunction{updateView} method updates the
  view when the model 
  has changed.  This method takes two parameters: object, which is the view
  object, and vData, which is a list of the following four elements: row name,
  column name, old value and new value.  This information passed in the
  parameters allows the programmer to update the view so it is synchronized
  with the model.  The \Rfunction{redrawView} method completely redraws the
  view.  Thus, the \Rfunction{redrawView} method only has one parameter:
  object, which is the view object to redraw.
  \item For the histogram view to be interactive, the view needs
  to respond to the following events: key press event, delete event,
  focus in event, the mouse button press event, and possibly the motion notify
  event.  The key press
  event adds accelerators to the view, the delete event ensures
  that the view list is current,
  and the focus in event ensures that
  the device is active when the histogram has the focus.  The mouse
  button press event allows the user to change plot information for
  the data (such as the color of a histogram bin) by interacting with the
  view.  Similarly, the motion notify event, if the programmer wants to
  respond to it, would let the user interact with the view by moving the
  cursor over the view.  Responding to these events is set in the
  \Rfunction{initialize} method for this new view class, which is defined by
  the programmer.  
\end{list}
\textbf{Extensions:}
%\newcounter{spacerule}
\begin{list}{\textbf{\arabic{spacerule}. }}
              {\setlength{\leftmargin}{0.5in}
               \setlength{\itemsep}{0in}
               \usecounter{spacerule}}
  \item Other events besides those listed in step four may need to be
  noticed depending on what interactivity the programmer wants to
  support. 
  \item A controller, such as a slider, can be added to the histogram
               view to control the histogram bandwidth. 
\end{list}

\section{\Rpackage{iSPlot} Functionality}\label{Sec:Func}

Some of the functionality available through the control window in
\Rpackage{iSPlot} is discussed here along with how it relates to how the
package has been designed.  All of the functionality discussed below is also
available through command line functions.  For a full explanation of
\Rpackage{iSPlot} capabilities, please see the \Rpackage{iSPlot} vignette.

\subsection{Event}\label{Ssec:EventMenu}

As mentioned in Section \ref{Sssec:Control}, the control window
controls the user interaction with views and this particular task is
implemented in the Event menu on the control window.  The Event menu lets the
user change the response to an event.  For example, the menu items under the
Event menu let the user set the response to a mouse over event, a left button
click event, a middle button click event, and a right button click event.
Suppose the user chooses the Set Left Button Click menu item under the Event
menu.  The user is then presented with several radio buttons that let
the user set the response to the left button click event.  For now, the
potential responses for the left button click event are color a point, hide a
point, highlight a point, and no action (i.e. no response).  These options
are all callback functions that have been defined by creating an instance of
class \Rclass{gEventFun}, which was explained in Section \ref{Sssec:Event}.

By designing the linking of callback functions with events in this manner, the
user can either use one of the predefined callback functions for an event or
the user can create his or her own callback function by defining an object of
class \Rclass{gEventFun}.  Thus, a user can change at any time the response
to a left button click event by using the Event menu.  Also, if the user
wanted a callback function that changed the plotting character of a point, for
example, the user could create an object of class \Rclass{gEventFun} that
represents this callback function.  This can be done directly on the command
line by calling the function, \Rfunction{addCBFunction}, and the man page for
this function gives an example of creating a new callback function for
changing the plotting character.  Then after this instance has been created,
the user could set the left button click event to change the plotting
character.  This flexibility lets the user decide the response to events and
lets the user extend the options for an event.  Notice that this design lets
the user have different responses to a left button click event versus a middle
button click event, for example.  For more details about the Event menu please
see the \Rpackage{iSPlot} package vignette.

\subsection{Find}\label{Ssec:Find}

Find is a menu option under the Edit menu on the control window, but it
can also be activated through the accelerator, Ctrl-F.  Find
allows a user to look for a particular row or a data element in a data
set.  When the user enters the row or element he or she wants to
find, the callback function that is linked to the left button click event
is called.  

For example, suppose that a user wants to find row ``Ohio'' in a data
frame where the row names are state names and the left button click event is
set to highlight a point.  Then by finding ``Ohio'', any points that
reflect that row in the data frame become highlighted.  This highlighting
of points on a view happens in two steps.  First, a
\Robject{gUpdateDataMessage} object is created that updates the
\Rslot{virtualData} slot in the model object.  Then, after the data have
changed, a \Robject{gUpdateViewMessage} object is created and handled so that
all views highlight points that represent ``Ohio''.

\subsection{Reset}\label{Ssec:Reset}

Reset is also a menu option under the Edit menu on the control window.  It
can be activated by clicking on the Reset menu item or by using the
accelerator, Ctrl-T.  Reset removes any changes
made to the data set since the data were loaded.  Reset performs
this action by resetting the \Rslot{virtualData} slot in the model object back
to its default values through a \Robject{gUpdateDataMessage} object.  If there
are views that display the data, a \Robject{gUpdateViewMessage} object is
created and handled so that the views are updated.

\section{Discussion}\label{Sec:Disc}

The goals of the software discussed in this paper were to create views that
are linked, views that are interactive, and a design that is extensible.
Constructing linked views was achieved by using the model, view, controller
paradigm, which is a widely used and well understood design.  In addition, by
carefully implementing the MVC design using S4 classes and inheritance in
\textsf{R} for the model, view, and message components, users can make
extensions to the model, view, and message classes.  An example discussed in
the Use Case in Section \ref{Sssec:Extens} created a histogram view class that
inherited from existing view classes in the \Rpackage{MVCClass} package.  To
extend the model, view, and message classes, the user only needs to know the
\textsf{R} language. 

The second goal of creating interactive views was realized by using the
\Rpackage{RGtk} and \Rpackage{gtkDevice} packages, which connected \textsf{R}
to Gtk+'s functionality.  Because Gtk+ is such a rich toolkit, many events can
be accessed, which allows a more interactive environment for the user.  Also,
users can make additions to the interactivity that is currently implemented.
Users can add signal handlers for events that are presently not caught and
this extension again only requires that the user program in \textsf{R}.  More
likely, though, the user may want to change the response to an event.  The
\Rclass{gEventFun} class was created so that users can encapsulate the
functionality needed for a new response to an event in one \Robject{gEventFun}
object.  Once a new \Robject{gEventFun} object has been created by the user,
this response can be linked to an event through either the GUI or through
command line functions.  Creating this new response again only requires that
the user program in \textsf{R}.

The final goal was to create an extensible design.  Extensibility was
incorporated in several places in the design of this software.  Several
examples of extensibility were already given in previous paragraphs, such as
adding new model, view, and message classes as well as changing the response
to an event.  Users can also add new functionality to the GUI (the control
window) using certain command line functions, which add a menu item to the GUI
and link it to a function they have created.  An important concern for
creating an extensible design was that users only need to know one
programming language to make additions.  Thus, the software was designed such
that all extensions can be done in the \textsf{R} language. 

The functionality that is currently available in the \Rpackage{iSPlot}
package through either the GUI or command line functions lets the user perform
exploratory data analysis on two-dimensional data.  However, the hope is that
the design encourages users to make additions based on the needs of their
data.  By giving users a tool for visualizing their data that is
designed to be extensible, users have great flexibility in determining how to
visually present and explore their data. 

\clearpage

\section*{Appendix}

\subsection*{Implementation}

In Sections \ref{Ssec:Overview} and \ref{Ssec:Details}, the design of
\Rpackage{iSPlot} and \Rpackage{MVCClass} was discussed, but certain
implementation decisions were also mentioned.  Here, more details of how
\Rpackage{iSPlot} was implemented are given.

Although each \Robject{MVC} object uses the \Rslot{controller} slot as an
environment to store information about that \Robject{MVC} object, there still
needs to be an overall environment that stores information for the software as
a whole.  This environment is called, \Robject{mvcEnv}, and it is created in
the \Rpackage{iSPlot} package.  The \Robject{mvcEnv} environment stores
information such as the list of loaded \Robject{MVC} objects, the name of the
\textit{active} \Robject{MVC} (\textit{active} model), the Gtk+ window that is
the control window, the menus for the control window, and any default
values that apply to all \Robject{MVC} objects, such as the default values for
the \Rslot{virtualData} slot in a model object.  

Also, as mentioned several times previously, the API of the
\Rpackage{iSPlot} package can be accessed through either a GUI front end or
through command line functions.  To learn more about the command line
functions, please see the \Rpackage{iSPlot} package vignette. 

\subsection*{Example Event}

An example of the steps that occur in response to an event is
given here.  For these steps, the active view, which is the view with focus,
is a scatter plot and the left button click event causes a point to be
colored. 

\begin{list}{\textbf{\arabic{spacerule}. }}
              {\setlength{\leftmargin}{0.5in}
               \setlength{\itemsep}{0in}
               \usecounter{spacerule}}
  \item First the user clicks with the left button on a point on the active
  scatter plot.  Suppose that the current color is red.
  \item The mouse button press event on the view emits a signal
               that is caught by the Gtk+ drawing area signal
               handler.
  \item The signal handler for the drawing area calls the
               \Rfunction{clickEvent} method for the
               \Robject{sPlotView} object.
  \item The \Rfunction{clickEvent} first determines if there is a callback
  function assigned to the left button click event and for this example, the
  callback function assigned to the left button click event is to color a
  point. 
  \item The \Rfunction{clickEvent} next determines if the mouse button
               press event occurred over a point on the plot and if it
               did, then the callback function is called and this callback
               function creates and handles a \Robject{gUpdateDataMessage}
               object to update the data in the model that this view
               represents (note that the model does not need to be the
               \textit{active} model).
  \item When the \Robject{gUpdateDataMessage} object is handled in the
               \Rfunction{handleMessage} method, the data in the model
               are updated and then a \Robject{gUpdateViewMessage}
               object is created and handled.
  \item When the \Robject{gUpdateViewMessage} object is handled in the
               \Rfunction{handleMessage} method, the \Rfunction{updateView}
               method is called to update the views of this model. 
  \item Now any view showing this point has the point colored red.

\end{list}

\subsection*{Code for a Callback Function}

Here is an example of \textsf{R} code for a callback function.  This is the
callback function for a mouse button press event on a Gtk+ drawing
area.  The function, \Rfunction{gtkAddCallback}, connects the event to
the callback function so \Rfunction{gtkAddCallback} is the signal
handler.  Now when a mouse button press event occurs, this callback
function calls the \Rfunction{clickEvent} method for the view object. 

\begin{verbatim}
  gtkAddCallback(drArea(curView), "button_press_event",
    function(obj, ev)
    {
      clickEvent(curView, ev)
      return(TRUE)
    }
  )
\end{verbatim}

Many other examples of callback functions are found in the
\Rpackage{iSPlot} code.

\bibliography{iSPlotPaper2}

\end{document}



















