[rkward-cvs] SF.net SVN: rkward:[3327] branches/jss_dec_10/FINAL_JSS_TEX

sjar at users.sourceforge.net sjar at users.sourceforge.net
Mon Dec 27 01:03:14 UTC 2010


Revision: 3327
          http://rkward.svn.sourceforge.net/rkward/?rev=3327&view=rev
Author:   sjar
Date:     2010-12-27 01:03:14 +0000 (Mon, 27 Dec 2010)

Log Message:
-----------
* section -> Section
* Background section final word redone

Modified Paths:
--------------
    branches/jss_dec_10/FINAL_JSS_TEX/GUI_elements.tex
    branches/jss_dec_10/FINAL_JSS_TEX/background.tex
    branches/jss_dec_10/FINAL_JSS_TEX/example_plugin.tex
    branches/jss_dec_10/FINAL_JSS_TEX/technical.tex

Modified: branches/jss_dec_10/FINAL_JSS_TEX/GUI_elements.tex
===================================================================
--- branches/jss_dec_10/FINAL_JSS_TEX/GUI_elements.tex	2010-12-26 17:53:47 UTC (rev 3326)
+++ branches/jss_dec_10/FINAL_JSS_TEX/GUI_elements.tex	2010-12-27 01:03:14 UTC (rev 3327)
@@ -1,7 +1,7 @@
 \section{Main elements of the user interface}
 \label{sec:user_interface}
 This section gives an overview of the main user interface elements and features of RKWard.
-For a use-case oriented example of an RKWard session, see section~\ref{sec:using_RKWard}.
+For a use-case oriented example of an RKWard session, see Section~\ref{sec:using_RKWard}.
 
 The default layout of the main application window is divided into five
 parts, as depicted in Figure~\ref{fig:main_window}. While many aspects
@@ -16,7 +16,7 @@
 persistent, even if no actions are available for that menu in the
 current context. The menu bar of the main window is also the central
 access point to most data import, manipulation, analysis, and
-visualization features (see section~\ref{sec:analyzing_data}) for which RKWard provides a GUI
+visualization features (see Section~\ref{sec:analyzing_data}) for which RKWard provides a GUI
 interface.
 
 \begin{figure}[htp]
@@ -47,21 +47,21 @@
 document view area (see below) is automatically re-sized to take up the
 free space.
 
-The left panel (Figure~\ref{fig:main_window}B) contains a file browser (see section~\ref{sec:further_tool_windows}) and a
-workspace browser (see section~\ref{sec:workspace_browser_object_viewer}) by default. The
+The left panel (Figure~\ref{fig:main_window}B) contains a file browser (see Section~\ref{sec:further_tool_windows}) and a
+workspace browser (see Section~\ref{sec:workspace_browser_object_viewer}) by default. The
 bottom panel (Figure~\ref{fig:main_window}D) contains the tool windows, namely, Command
-log (section~\ref{sec:further_tool_windows}), Pending Jobs (section~\ref{sec:further_tool_windows}), \proglang{R} Console
-(section~\ref{sec:using_R_console}), and Help Search (section~\ref{sec:help_system}).
+log (Section~\ref{sec:further_tool_windows}), Pending Jobs (Section~\ref{sec:further_tool_windows}), \proglang{R} Console
+(Section~\ref{sec:using_R_console}), and Help Search (Section~\ref{sec:help_system}).
 
 The remainder of the central area (Figure~\ref{fig:main_window}C) is a single row Tab Document
 Interface (TDI) for different documents. Early uses of TDIs date back to 1988 and are
 widely applied nowadays \citep{Hopkins2005, MDN2010,
 KimLutteroth2010}. Currently, the supported types of
-documents are object summaries (section \ref{sec:workspace_browser_object_viewer}), 
-script editors (section~\ref{sec:code_editor}), spreadsheet-like data editors 
-(section~\ref{sec:spreadsheet}), results output (section~\ref{sec:results_output}), 
-help pages (section~\ref{sec:help_system}), and also
-\proglang{R} onscreen graphics devices (section~\ref{sec:technical_graphics}). 
+documents are object summaries (Section~\ref{sec:workspace_browser_object_viewer}), 
+script editors (Section~\ref{sec:code_editor}), spreadsheet-like data editors 
+(Section~\ref{sec:spreadsheet}), results output (Section~\ref{sec:results_output}), 
+help pages (Section~\ref{sec:help_system}), and also
+\proglang{R} onscreen graphics devices (Section~\ref{sec:technical_graphics}). 
 The order of tabs can be conveniently re-arranged
 using drag \& drop.
 
@@ -81,7 +81,7 @@
 configure data editor shortcuts, one has to open a data editor first and
 then to select ``Settings$\rightarrow$Configure Shortcuts''. Since RKWard relies on the 
 \proglang{KDE} SC editor component,
-shortcuts for the script editor (section~\ref{sec:code_editor}) are managed separately via 
+shortcuts for the script editor (Section~\ref{sec:code_editor}) are managed separately via 
 ``Settings$\rightarrow$Configure Editor$\rightarrow$Shortcuts''. On most systems, it is also
 possible to configure shortcuts by right-clicking on the respective
 menu item.
@@ -123,7 +123,7 @@
 \proglang{R} help for information on that object, to
 open a window with detailed information on the object, to delete, rename or copy the object to a new symbol name, or to
 copy it to \code{.GlobalEnv}. Further, the context menu allows to open
-supported types of objects for editing (see section~\ref{sec:spreadsheet}; currently, only
+supported types of objects for editing (see Section~\ref{sec:spreadsheet}; currently, only
 \code{data.frame}s can be edited, and only while they exist in \code{.GlobalEnv}). 
 Selecting ``View'' from the 
 context menu opens a new window in the
@@ -133,7 +133,7 @@
 
 An object list similar to the workspace browser (but showing only 
 \code{.GlobalEnv} by default) is also used in several places for the
-selection of objects to work with, e.\,g., in an analysis plugin (see section~\ref{sec:analyzing_data}).
+selection of objects to work with, e.\,g., in an analysis plugin (see Section~\ref{sec:analyzing_data}).
 
 
 \subsection{Code editor}
@@ -205,7 +205,7 @@
 
 However, for most purposes RKWard's \proglang{R} console can be used exactly
 like \proglang{R} running in a terminal. Adding to that, it provides many of the
-features which are also available in the code editor (see section~\ref{sec:code_editor}).
+features which are also available in the code editor (see Section~\ref{sec:code_editor}).
 Most prominently, it supports syntax highlighting, code
 folding, function argument hinting, object-name completion, and pasting
 vector or matrix data directly from the clipboard.
@@ -215,7 +215,7 @@
 pages, is sent through the \proglang{R} console.
 However, it can be configured to the submitted in the background,
 instead.
-For further technical details, see section \ref{sec:technical}.
+For further technical details, see Section~\ref{sec:technical}.
 
 \subsection{Spreadsheet-like data editor}
 \label{sec:spreadsheet}
@@ -300,7 +300,7 @@
 \proglang{R} engine. 
 This general pattern, implemented as plugins, is the
 basic recipe for most of the functionality provided by RKWard
-(see section~\ref{sec:technical_plugins} for details). 
+(see Section~\ref{sec:technical_plugins} for details). 
 Note that on purpose, RKWard does not have its
 own file format for data import and export. That is, it is possible
 to import data from several sources (see below) or to save and load
@@ -315,9 +315,9 @@
 relies on \proglang{R} packages for certain sets of
 data which were already described elsewhere
 \citep{Murdoch2002}. Of course, further formats can
-also be imported using copy \& paste (see sections~\ref{sec:code_editor} and \ref{sec:spreadsheet}), or by
+also be imported using copy \& paste (see Sections~\ref{sec:code_editor} and \ref{sec:spreadsheet}), or by
 manually entering appropriate \proglang{R} commands in
-the \proglang{R} console (section~\ref{sec:using_R_console}). To import CSV
+the \proglang{R} console (Section~\ref{sec:using_R_console}). To import CSV
 data, select ``File$\rightarrow$Import format$\rightarrow$Import Text$\rightarrow$CSV''
 data from the menu. This will open the dialog shown in
 Figure~\ref{fig:import_data}A. The central area of this dialog provides 
@@ -335,7 +335,7 @@
 
 The bottom area optionally shows the \proglang{R}
 code corresponding to the current settings, and which will be run
-upon pressing the ``Submit button'' (see section~\ref{sec:importing_data} for generated \proglang{R} code). 
+upon pressing the ``Submit button'' (see Section~\ref{sec:importing_data} for generated \proglang{R} code). 
 The code display is hidden by default and can be revealed using
 the ``Code'' button. This 
 generated code display is updated dynamically as the user changes settings, allowing
@@ -344,7 +344,7 @@
 Most data handling functions will produce some output, which is
 sent to the output window. From there it is possible to repeat the
 action by clicking on the ``Run again''-link
-(see section~\ref{sec:results_output}).
+(see Section~\ref{sec:results_output}).
 
 \subsection{Graphics window and plot previews}
 \label{sec:plot_previews}
@@ -392,7 +392,7 @@
 shows the plot as it would be created with the current settings. The
 preview is updated automatically as the user makes changes, allowing to
 see the effect of each setting instantly\footnote{The preview is
-updated asynchronously to keep the GUI responsive; see section~\ref{sec:technical_graphics}.}. For example, the CLT plugins
+updated asynchronously to keep the GUI responsive; see Section~\ref{sec:technical_graphics}.}. For example, the CLT plugins
 under the ``Distributions'' menu can be very helpful to dynamically ``show''
 the convergence in distribution while teaching. For the sake of simplicity, such preview plots are not added to
 the history.
@@ -404,7 +404,7 @@
 capturing and documenting \proglang{R} output can also
 be used, RKWard provides a dedicated output file and a output
 window for documenting the results. All GUI-driven data handling
-functions (see section~\ref{sec:analyzing_data}) write their output to this file. 
+functions (see Section~\ref{sec:analyzing_data}) write their output to this file. 
 The same applies to error messages, in case a plugin fails to perform its task.
 The output is presented in a journal format\footnote{Note: The font size of the output can be adjusted
 from the menu. 
@@ -541,7 +541,7 @@
 The former includes documentation on \proglang{R} functions and packages 
 and the various R manuals; while the later includes help pages on 
 RKWard in general and on specific GUI dialogs\footnote{For technical 
-backgound of RKWard GUI help pages please refer to section~\ref{sec:technical_plugins_defining}.}. 
+backgound of RKWard GUI help pages please refer to Section~\ref{sec:technical_plugins_defining}.}. 
 All these various types of help pages can be browsed in the same document 
 window, and are appropriately cross--linked. For example, help pages for
 RKWard GUI dialogs will typically link to documentation for both

Modified: branches/jss_dec_10/FINAL_JSS_TEX/background.tex
===================================================================
--- branches/jss_dec_10/FINAL_JSS_TEX/background.tex	2010-12-26 17:53:47 UTC (rev 3326)
+++ branches/jss_dec_10/FINAL_JSS_TEX/background.tex	2010-12-27 01:03:14 UTC (rev 3327)
@@ -34,7 +34,7 @@
 or by allowing to implement routinely performed tasks as a GUI element. In
 addition, many features like the integrated data editor and the plot preview 
 will be useful to \proglang{R} novices and \proglang{R} experts alike in their everyday work
-(see section \ref{sec:user_interface}).
+(see Section \ref{sec:user_interface}).
 
 RKWard provides a high level of transparency about the steps that are needed to
 perform any supported task in \proglang{R}, in order to make it easy for the user to see
@@ -60,7 +60,7 @@
 artificial limitations on how users can work with the application. For example,
 the user is not limited to using only one \code{data.frame} or one model at a
 time. RKWard is designed to allow users to even create custom GUI dialogs
-easily (see sections \ref{sec:technical_plugins} and \ref{sec:example_plugin}).
+easily (see Sections \ref{sec:technical_plugins} and \ref{sec:example_plugin}).
 
 RKWard is licensed under the terms of the GNU GPL (general public license) Version 2
 or higher. However, due to its dependencies, RKWard binaries are effectively
@@ -79,14 +79,10 @@
  \label{fig:timeline}
 \end{figure}
 
-%The rest of this paper is organized as follows: Section \ref{sec:user_interface} gives an 
-%overview of the main GUI elements and features of RKWard, followed by a short example 
-%of a simple RKWard session in Section \ref{sec:using_RKWard}.
-%Next, Section \ref{sec:technical} discusses some technical aspects of the implementation, comparing them briefly to competing GUI solutions, where appropriate. An example for creating a simple plugin extension to RKWard is shown in Section \ref{sec:example_plugin}.
-%Finally, some closing comments are made in Section \ref{sec:conclusion_summary}.
-
 In this paper we will first give an overview over the main GUI elements and
-features of RKWard. Next some technical aspects of the implementation will be
-dicussed, followed by a short example of a simple RKWard session, comparing 
-them briefly to competing GUI solutions, where appropriate. Additionally,
-we show an example for creating a simple plugin extension to RKWard.
+features of RKWard (Section~\ref{sec:user_interface}), followed by a short example 
+of a simple RKWard session (Section~\ref{sec:using_RKWard}). Next technical 
+details of the implementation will be discussed, comparing them briefly to 
+competing GUI solutions, where appropriate (Section~\ref{sec:technical}).
+Finally, we show an example for creating a plugin extension to RKWard 
+(Section~\ref{sec:example_plugin}).
\ No newline at end of file

Modified: branches/jss_dec_10/FINAL_JSS_TEX/example_plugin.tex
===================================================================
--- branches/jss_dec_10/FINAL_JSS_TEX/example_plugin.tex	2010-12-26 17:53:47 UTC (rev 3326)
+++ branches/jss_dec_10/FINAL_JSS_TEX/example_plugin.tex	2010-12-27 01:03:14 UTC (rev 3327)
@@ -1,7 +1,7 @@
 % !TEX root = RKWard_paper.tex
 \section{Extending RKWard - an example of creating a plugin}
 \label{sec:example_plugin}
-As discussed in section~\ref{sec:technical_plugins}, plugins in RKWard are
+As discussed in Section~\ref{sec:technical_plugins}, plugins in RKWard are
 defined by four separate files (Figure~\ref{fig:plugin_structure}). To give an impression of the technique,
 this section shows (portions of) the relevant files for a plugin that provides
 a simple dialog for a t-test. For brevity, the help-file is omitted.

Modified: branches/jss_dec_10/FINAL_JSS_TEX/technical.tex
===================================================================
--- branches/jss_dec_10/FINAL_JSS_TEX/technical.tex	2010-12-26 17:53:47 UTC (rev 3326)
+++ branches/jss_dec_10/FINAL_JSS_TEX/technical.tex	2010-12-27 01:03:14 UTC (rev 3327)
@@ -2,7 +2,7 @@
 \label{sec:technical}
 In this section we will give a compact overview over key aspects of RKWards
 technical design. We will give slightly more attention to the details of the
-plugin framework (section~\ref{sec:technical_plugins}) used in RKWard, since this is central to the extensibility of
+plugin framework (Section~\ref{sec:technical_plugins}) used in RKWard, since this is central to the extensibility of
 RKWard.
 
 \subsection{Asynchronous command execution}
@@ -13,7 +13,7 @@
 time-consuming analysis. For instance, while waiting for the estimation of a
 complex model to complete, the user should be able to continue to use the GUI to
 prepare the next analysis. Asynchronous command execution is also a prerequisite
-for an implementation of the plot-preview feature (see section~\ref{sec:plot_previews}). Commands
+for an implementation of the plot-preview feature (see Section~\ref{sec:plot_previews}). Commands
 generated from plugins or user actions are placed in queue and are evaluated in
 a separate thread in the order they were submitted\footnote{
     It is possible, and in some cases necessary, to enforce a different order of command execution in
@@ -23,11 +23,11 @@
 }. The asynchronous design implies that RKWard avoids to rely on the
 \proglang{R} engine during interactive use. This is one of several reasons for
 the use of \proglang{ECMAScript} in plugins, instead of scripting using
-\proglang{R} (see sections~\ref{sec:technical_toolkit} and \ref{sec:technical_plugins}).
+\proglang{R} (see Sections~\ref{sec:technical_toolkit} and \ref{sec:technical_plugins}).
 A further implication is that RKWard avoids querying information about the
 existence and properties of objects in \proglang{R} interactively. Rather,
 RKWard keeps a representation of \proglang{R} objects and their basic properties
-(e.\,g., class and dimensions), which is used for the workspace browser (section~\ref{sec:workspace_browser_object_viewer}),
+(e.\,g., class and dimensions), which is used for the workspace browser (Section~\ref{sec:workspace_browser_object_viewer}),
 object name completion, function argument hinting and
 other occasions. The object representation includes objects in all environments
 in the search path, and any objects contained within these environments in a
@@ -66,7 +66,7 @@
 workspace browser, object selection lists, and object views. Beyond that,
 detecting any changes is particularly important with respect to objects which
 are currently opened for editing in the data editor (which provides an illusion
-of in-place editing, see section~\ref{sec:spreadsheet}). Here, it is necessary to synchronize
+of in-place editing, see Section~\ref{sec:spreadsheet}). Here, it is necessary to synchronize
 the data between \proglang{R} and the GUI in both directions.
 
 For simplicity and performance, object modification detection is only
@@ -136,7 +136,7 @@
 the various components of RKWard.
 
 Plugins in RKWard rely on \proglang{XML} (Extensible Markup Language)\footnote{\url{http://www.w3.org/XML/}}
-and \proglang{ECMAScript}\footnote{\url{http://www.ecmascript.org/}} (see section~\ref{sec:technical_plugins}). \proglang{XML} is not
+and \proglang{ECMAScript}\footnote{\url{http://www.ecmascript.org/}} (see Section~\ref{sec:technical_plugins}). \proglang{XML} is not
 only well suited to describe the layout of the GUI of plugins, but simple
 functional logic can also be represented \citep{Visne2009}. \proglang{ECMAScript} was
 chosen for the generation of \proglang{R} commands within plugins, in particular due to its
@@ -210,7 +210,7 @@
 \subsubsection{Defining a plugin}
 \label{sec:technical_plugins_defining}
 Plugins consist of four parts as visualized in Figure~\ref{fig:plugin_structure} 
-\citep[see section~\ref{sec:example_plugin} for an example; for a complete
+\citep[see Section~\ref{sec:example_plugin} for an example; for a complete
 manual, see][]{Friedrichsmeier2010}:
 
 \begin{figure}[htp]
@@ -223,7 +223,7 @@
 
 \begin{itemize}
     \item
-    An \proglang{XML} file (section~\ref{sec:defining_menu_hierarchy}), 
+    An \proglang{XML} file (Section~\ref{sec:defining_menu_hierarchy}), 
     called a \textbf{plugin map}, is used to declare one or more plugins, each
     with a unique identifier. For most plugins, the plugin map also defines the
     placement in the menu hierarchy. Plugin maps are meant to represent groups of
@@ -231,7 +231,7 @@
     complexity of the menu hierarchy.
 
     \item
-    A second \proglang{XML} file describes the \textbf{plugin GUI layout} itself (section~\ref{sec:defining_dialog_ui}). 
+    A second \proglang{XML} file describes the \textbf{plugin GUI layout} itself (Section~\ref{sec:defining_dialog_ui}). 
     Most importantly this includes
     the definition of the GUI-layout and GUI-behavior. High level GUI-elements can
     be defined with simple \proglang{XML}-tags. Layout is based on ``rows'' and ''columns'',
@@ -244,7 +244,7 @@
     behavior using \proglang{ECMAScript}.
 
     \item
-    A separate \textbf{\proglang{ECMAScript} file} (section~\ref{sec:generating_r_code_from_ui_settings}) 
+    A separate \textbf{\proglang{ECMAScript} file} (Section~\ref{sec:generating_r_code_from_ui_settings}) 
     is used to translate GUI settings into \proglang{R}
     code\footnote{
         In earlier versions of RKWard, \proglang{PHP} was used
@@ -302,7 +302,7 @@
 \code{HTML()} function of the \pkg{R2HTML} package \citep{Lecoutre2003} in the current
 implementation. The use of custom formatting with \proglang{HTML} is possible, but
 discouraged. Standard elements such as a horizontal separator, and the ``Run again''
-link (see section~\ref{sec:results_output}) are inserted automatically, without the need to define
+link (see Section~\ref{sec:results_output}) are inserted automatically, without the need to define
 them for each plugin.
 
 Regarding the style of the generated \proglang{R} code, enforcing consistency is harder,
@@ -335,7 +335,7 @@
 of the plugins depend on \proglang{R} packages other than the recommended \proglang{R} base packages.
 Examples herein are the calculation of kurtosis, skewness or the exact Wilcoxon
 test. Installation of additional packages is handled automatically by RKWard
-(see section~\ref{sec:package_management}).
+(see Section~\ref{sec:package_management}).
 
 RKWard avoids loading all these packages pro-actively, as \pkg{Rcmdr} does. Rather,
 plugins which depend on certain package simply include an appropriate call to


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.




More information about the rkward-tracker mailing list