diff --git a/ChangeLog b/ChangeLog
index 9651ac60..87b2eb7f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,1017 +1,1018 @@
+- Added context menu option to search for information on current symbol online
 - Fixed: Wizard plugins would be too small, initially
 - Fixed: Help Search was not longer working correctly with R 3.2.x
 - Fix compilation with R 3.3.x
 - Provide better status feedback when searching / filtering among installable packages
 - Add access to basic menu items for docked previews
-- Move preview controls to the button-column of dialogs                                            TODO document, polish
+- Move preview controls to the button-column of dialogs
 - Add preview to Sort data-, Subset data, and Recode categorical data-plugins
 - Add preview to Power Analysis plugin
 - Add support for adding "htmlwidget"- and "gvis"-class objects to the output window via rk.print()
 - Add plugins for importing Excel files (.xls and .xlsx, Perl- and Java-based)
 - Add ability to extract <matrix> values row-wise in plugins
 - Add convenience JS-function "makeOption()" for use in plugins
 - Fixed: Numerical (display) precision setting was not honored in data editor
 - Fix several window activation quirks in "Focus follows mouse" mode
 - File selectors in "Import XYZ" plugins now filter for standard file extensions, by default
 - Add previews for CSV, SPSS, and Stata import plugins
 - Allow previews for data, (HTML) output, and custom types of previews
-- Allow previews to be docked to the dialog window, and dock them, by default                      TODO: update documentation on placemnet
+- Allow previews to be docked to the dialog window, and dock them, by default
 - Implicitly save code preview visibility and size (instead of the former explicit settings)
 - data.frame objects outside of globalenv() can be opened read-only in an editor window
 - Show a warning screen when invoking plugins from the command line (or from clicking an rkward://-link in an external application)
 - Use package type option "binary" from R 3.1.3 onwards, for automatic selection of the appropriate binary package
 
 --- Version 0.6.4 - Dec-20-2015
 - Fixed: Plugin variable slots taking more than one object would not be hightlighted in red while invalid
 - Plugins check for correct object type, in more places, but allow to proceed with questionable object selections
 - Fixed: RKWard package repository would be listed twice on fresh installations
 - Switch to bugs.kde.org as primary issue tracker
 - Workspace browser gains functionality to search / filter objects by name
 - Separate globalenv() and other environments in the search path more clearly in workspace browser
 - Fix some minor toolbar glitches
 - Complete rework of <optionset> UI for better usability
 - Try harder to honor system locale settings
 - Remove obsolete "Export tabular data" plugin (superceded by "Export Table / CSV")
 - Some usability refinements to "Import CVS" plugin
 - Disabled the "Import Data"-dialog, as it was considered too confusing. The individual importers are still available from the menu, separately.
 - For multi-item varslots and valueslots, use separate buttons for adding / removing items
 - Don't show (useless) index number in mutli-value varslots and valueslots
 - Make the option to disable / enable editing more visible (in the data editor's toolbar)
 - Do not invoke symbol name completion while in the middle (not end) of a word
 - Add context menu to HTML viewer window, including the ability to open links in a new window
 - Remove dependency on KHMTLPart
 
 --- Version 0.6.3 - Mar-07-2015
 - Fixed: Hang when trying to select existing directories in file selectors on Windows
 - New element <i18n> for use in plugins' logic section: Provides a translatable string property
 - New element <label> for use in plugin help pages: Copies the label-attribute of the given element into the text
 - New string property modifier "quoted" to make it easier to quote dynamic strings inside plugins
 - Reworked distribution calculator plugins
 - Added power analysis plugin (already existed as separate plugin)
 - Assume plugin .js files to be in utf-8 encoding; this allows using non-ascii characters in the generated code
 - <matrix> element gains options min_rows and min_columns, and the details of fixed_width="true" have been improved
 - Fixed: <valueslot>s were quirky with respect to showing as invalid
 - Fix a hang-on-exit issue
 - Add R function rk.set.plugin.status() to allow further customization of loaded plugins (hiding of individual menu entries)
 - Pluginmap-management was reworked, partially, and moved to Settings->Manage R packages and plugins
 - Provide more detailed information on loaded plugins in rk.list.plugins()
 - Allow to override plugins from a different pluginmap (the plugin with the highest specified version is used)
 - Fixed: Error when using fix() or trace(...edit=TRUE) with default settings on some systems
 - When the RKWard installation has moved on disk, try to adjust stored .pluginmaps paths, accordingly
 - Fixed: Freezes when using RKWard-functionality (such as the RK()-device) from tcl/tk (e.g. Rcmdr)
 - Allow opening RKWard's plugin files (with correct highlighting), and other text files
 - More robust control over placement of plugins within a menu
 - Fix several issues of excessive printing of digits in plugins' output
 - Restructure layout of CSV-import dialog
 - Allow to open (any number of) R script files and rkward://-urls from the command line
 - Add command line option --reuse for reusing an existing instance of RKWard
 - Be slightly(!) smarter about when (not) to ask for saving workspace on workspace load (e.g. not directly after workspace has been saved)
 - Change default in Workspace browser to showing only .GlobalEnv, initially
 - Support automatically generating a printable header parameter from most plugin elements
 - New Object based convience method for printing headers from plugins
 - Implement polyPath()-drawing in RK() device
 - Pre-compile the common js code included in every plugin (only when compiled with Qt >= 4.7)
 - Improve crash recovery dialog to not prompt again for the same files
 - Fixed potential crash while the "RKWard Debug Messages" window is visible
 - Fixed display of file paths containing non-ascii characters in the title bar and startup dialog
 - Fixed some erroneous plugin debug messages
 - Plugins and in-application help pages can now be fully translated
 
 --- Version 0.6.2 - Oct-20-2014
 - In data editor, indicate NAs, explicitly
 - Import Stata plugin gains option to convert character encoding.
 - New plugin for recoding categorical data
 - New embeddable (minimal) plugin "multi_input" to combine different input elements
 - Fixed: Problems starting from paths with spaces in the file name on Windows
 - Added command line option --r-executable for switching between several installations of R
 - Use a binary wrapper, instead of wrapper shell script for startup on all platforms
 - Linear regression plugin gains option to save predicted values
 - Fixed some compilation problems
 - Add basic support to export plots using tikzDevice
 - Fixed: cbind-value of <matrix> element was missing commas
 - Fixed: Give a label to an unlabelled toolbar
 - Fixed: Adjust to (re-?)named parameters for options("pager")
 - Allow plugin UI script code to query R for information
 - Fixed: potential crash when a previously installed pluginmap is not longer readable
 - Allow to connect <varslot>/<valueslot> source to any property, not just <varselectors>
 - New plugin elements <valueselector> and <select>
 - New plugin element <valueslot> for selecting arbitrary string values (otherwise almost identical to <varslot>)
 - <varslots> can be set to accept the same object several times. Used in scatterplot plugin.
 - New R function rk.embed.device() for manually embedding graphics devices in RKWard
 - Fixed: R backend would exit immediately, without meaningful error message, if there is an error in .Rprofile (or Rprofile.site)
 - Fixed: Installing suggested packages from the package installation dialog was broken
 - Fixed: Selecting a mirror via the "R packages" settings page would not work when prompted for package installation form the backend
 - Remove support for compiling RKWard in a single process (threaded) variant. This was not used / tested since RKWard 0.5.5
 - Shortcuts for the "Run ..." actions have been changed for better cross-platform compatibility
 - The script editor's "Run line" and "Run selection" actions have been merged
 - Add UI for configuring default graphics device, and embedding of standard graphics devices.
 - New RKWard native on-screen device (RK()). This is the default on-screen device in RKWard, now.
 - New R function rk.without.plot.history() for turning off plot history, temporarily
 - Add command line option --backend-debugger
 
 --- Version 0.6.1 - Apr-02-2013
 - Add option to force-close a graphics window
 - Add plugin for subsetting data.frames by rows or columns
 - On the Windows platform, add an new (experimental) binary startup wrapper (rkward.exe)
 - Revert to building R packages form source on Mac OS X by default (controllable via compile-time option)
 - Fixed: lattice plots would not be added to the plot history, correctly, for some versions of lattice
 - Fix crash when trying to print, and neither okular, nor kpdf are available
 - Added support for loaded namespaces that are not attached to a loaded package
 - Pluginmaps can specify their "priority". Pluginmaps with low priority will not be added automatically, when found.
 - Pluginmaps can <require> other pluginmaps based on their id (for cross-package inclusion)
 - Added new element <dependency_check> for dynamic version checks within a plugin (R and RKWard versions, only, so far)
 - Add guard against accidental usage of the standard distributed pluginmaps in a later version of RKWard (installed in parallel)
 - Easier (de-)activation of RKWard plugin maps using checkboxes (Settings->Configure RKWard->Plugins)
 - Broken or quirky .pluginmap files are reported to the user, completely broken maps are disabled, automatically
 - Implement basic dependency handling for plugins / pluginmaps
 - Added support for the upcoming R 3.0.0
 - Added <switch> logic element to switch between several target properties (or fixed values) based on the value of a condition property
 - Sort plugin gains option to sort data.frames by more than one column at a time, and options for type conversion
 - Add in-application debug message viewer (targetted at (plugin) developers)
 - Add setting to customize initial working directory
 - Windows only: Add UI-checkbox for R's "internet2"-option
 - New functions getString(), getList() and getBoolean() for fetching data in plugin scripts
 - Boolean properties now return a numeric, not labelled representation of their value, by default. <checkbox>es should be unaffected.
 - Added <optionset> GUI element for entering a set of options for an arbitrary number of items
 - Reduce CPU usage of pluings while idle
 - Fix conversion from Numeric to Factor in the data editor
 - In the data.frame editor, columns containing invalid values are now highlighted in red
 - Fixed: If none of the previous plugin maps could be found on startup, re-add the default
 - Added <matrix> GUI element for entering matrix or vector data in plugins
 - Improve key handling while editing factor levels in a data.frame
 - Added utiltity function rk.flush.output()
 - RKWard is now categorized as Science/Math/Numerical Analysis in its .desktop file
 - Fixed: Yet another fix for hard-to-read function argument hints
 - Fixed: Device history was not working with more recent versions of ggplot2
 - Fixed: Option to include suggested packages in install was mis-labelled "install dependencies"
 - rk.set.output.html.file() gains argument to allow addition of custom content to the html header
 
 --- Version 0.6.0 - Oct-24-2012
 - Fixed: Entering "0" as propabilities (quantiles) vector in distribution plugins would cause error message
 - Preview device windows will display some status information (most importantly, warnings or errors)
 - Most plot plugins gain options to control margins and tick label orientation
 - Added option for installing packages from source (implicitly enabled on Unixoid platforms)
 - Fixed: Wrong handling of carriage returns ('\r') in the console window
 - Fixed: Spinboxes had wrong initial values
 - Omit comments on missing function calls in dialog code windows (e.g., if prepare() is unused, there's no "## Prepare" in the output either)
 - Output markup is now more XHTML compliant and easier to parse
 - Also save cursor position, folding, etc. for scripts. Note: Implementation details may be subject to change.
 - New function rk.list.labels() to retrieve column labels in a data.frame
 - rk.get.label() will now return an empty string ("") instead of NULL, in case no label is assigned
 - Fixed: Changed configuration settings would not be saved for script editor
 - Fixed: One character missing in R commands on lines longer than 4096 characters
 - Fixed: "Next"-button in wizards would remain enabled while settings are missing on a page
 - Fixed: Dynamic pages in a wizard would cause a layout bug on the first page
 - Do not offer to restore individual removed columns of a data.frame opened for editing
 - Fixed: Plot history and graphical menus broken in some cases with R 2.15.0
 - Fixed: If the rkward package was loaded in a plain R session, q() and quit() still work
 - combined all Wilcoxon/Mann-Whitney-tests in one plugin (from previously two separate plugins)
 - Added polyserial/polychoric correlations to correlation matrix plugin
 - Added more compression options to the "Save objects as R code" plugin
 - Added MacPorts support, see README.MacPorts and bundle build script in the macports folder
 - Added dynamically generated table-of-contents menu to output document
 - Fixed: Would not show output of system() commands to stderr on the console (on Unix-like systems)
 - Allow some markup inside <text> elements in plugins, and auto-add breaks only for duplicate newlines.
 - Reorganized t-test plugin, and add support for single sample t-tests
 - Box plot plugin gains more options for adding means
 - Fixed: Function argument hints for the second half of the parameter list would not be quoted, correctly
 - Improve keypress handling issues in the R Console, when the cursor or a selection is outside the editable range
 - Fixed: Failure to open workspaces with non-latin1 filenames from the command line
 - Fixed: Saving / restoring workplace layout would fail when saving to directories with unusual characters
 - Only install translations which are at least 80% complete (not counting strings in plugins, which are not yet translatable)
 - When asking for workspace file to open, use appropriate file filter
 - When configured to ask for workspace to open on startup, don't prompt to save, first
 - Fixed: potential crash when clicking "Select all updates" in the package installation dialog
 - Fixed: potential crash in object name completion under certain conditions
 - Simplified the "Sort Data" plugin, and added a help page
 - Fixed: On Windows, detached windows would sometimes be positioned with the menubar outside the upper screen edge
 - Added GUI support for inspecting the call stack during debugging
 - The backend executable is no longer linked against KDE libraries
 - Objects, which are not acceptable in a varslot, will still be shown, there, with a warning
 
 --- Version 0.5.7 - Oct-23-2011
 - Fixed: Would not system-defined text color for argument hints
 - Do not treat arrays (which are not a matrix) as hierarchical named objects in the object browser
 - Do not analyse more than 100000 name child-objects per object (avoids hangs on such extreme data)
 - Fixed: Problems with using mclapply() inside RKWard
 - Offer to add a new library location, automatically, if location selected for installation is not writable
 - Reworked package installation / update dialog
 - Fixed: Integrated help browser would not update navigation history when following page internal links
 - Documentation on writing RKWard plugins is now accessible, locally
 - The file filter for R script files is now configurable, and includes *.Rhistory, by default
 - More obvious coloring of variable entry fields requiring user input in plugins
 - Default size of the code display in plugin dialogs has been increased
 - Removed support for downloading plugins using GHNS
 - Added support for RKWard plugins shipped inside R packages 
 - Fixed: PDFs and many other types of documents linked from help pages would not be opened, correctly
 - Added support R 2.14.x
 - Removed option to set options("printcmd")
 - New option to run arbitrary (setup) commands in each session
 - Added new pseudo graphics device "rk.printer.device" to provide printing via the KDE printer dialog
 - Fixed: Printing was broken when kprinter is not available
 - Support the results list new help.search() in R 2.14.x, which includes vignettes and demos
 - rk.edit.files() and rk.show.files() gain parameter "prompt", which can be used to suppress user prompt
 - Added function rk.demo(), which is similar to demo(), but opens the example script in a script editor window
 - Fixed: Some plugin dialogs would not become visible, or be shown in very small size, with some window managers
 - Fixed: Potential crash when using context menus with "focus follows mouse" window activation policy
 - Added shortcut Ctrl+Enter to insert a line break and submit from a script editor
 - Reduce CPU usage while idle
 - Bar plot, dot chart, pie chart, and Pareto plot plugins gain more tabulation options
 - rk.results() now prints rownames, where appropriate
 - "frame" elements in plugins can now be made checkable
 - Disabling or hiding a plugin component makes it non-required, implicitly
 - Box plot gains option to dogde grouped boxes
 - Simplify internal handling of system() and system2() output
 - Simplify code produced by several plugins
 - Fixed: Occasional duplication of first letter of keyword, when using "Copy lines to output" from the console window
 
 --- Version 0.5.6 - May-30-2011
 - Fixed: Would crash when searching for a term with quotes in the help search window
 - Add simple man page for command line options
 - Fixed: Potential crash when creating plots from a tcl/tk based GUI
 - Fix compilation on FreeBSD
 - Replace the R console's "Copy selection cleaned" action with "Copy commands, only", which will omit any non-command regions in the copy
 - Add "Copy lines to output" action to copy highlighted lines from the R console or script editors to the output window
 - R commands and their output can be "carbon copied" to the output window
 - On Windows, RKWard will detect, and offer to disable "native" file system dialogs
 - Object browsers that show only the global environment now hide the ".GlobalEnv" item
 - Fixed: Function argument hints would not be shown in some corner cases
 - Added function rk.print.code() to write highlighted R code to the output window
 - Box plot plugin gains support for grouped outcome data
 - Fixed: Pressing Ctrl+C would not reset syntactically incomplete commands in the R console
 - Crosstabs N to 1 plugin gains options to compute proportions and margins (thanks to Andrés Necochea)
 - Added convenience R function rk.list() to allow simplification of plugin code
 - Added stack-based window switching using Ctrl+(Shift)+Tab; this replaces the old "Next Window" and "Previous Window" actions
 - Fixed: Graphics device windows would disappear when trying to attach them to the main window with some versions of Qt
 - Fixed: tcl/tk widgets would lock up after running commands in the R Console
 - Provide a template for bug reports, containing standardized information on the RKWard setup in Help->Report Bug...
 - When loading a (local) workspace, change the working directory to the directory of the workspace (configurable)
 - Include the sidebar position of tool windows when saving / restoring the workplace layout
 - "Pending jobs" tool window is not longer shown in the bottom sidebar by default
 - Support removing individual tool windows from the sidebars, completely
 - Add an action to interrupt all (current and pending) commands
 - Fixed: When saving the workplace while closing the session, the workplace layout would not always be saved correctly
 - File browser context menu gains many more KDE standard actions (KDE 4.3 and above, only)
 - Auxiliary binaries rkward.bin and rkward.rbackend are no longer installed into /usr[/local]/bin/ on Unix
 - Fixed: Object name completion would abort early in the script editor with KDE 4.4
 - Support function argument hinting for R primitives
 - Support package namespaces in object name completion and workspace browser
 - Support S4 slots in object name completion and workspace browser
 - More correct handling of quotes in object name completion
 - Support plot history for ggplot2 plots
 - Be less pro-active about fetching structure information on R objects in the workspace
 - Allow to browse arbitrarily deeply nested environments in the object browser
 
 --- Version 0.5.5 - Mar-15-2011
 - Fixed: Crash when several environments on the search path have the same name
 - Re-organize the default toolbar actions of the main window
 - Detached windows are now restored in detached state when restoring the workplace layout
 - Workplace layout is now saved in a separate file, instead of in a hidden object inside the .RData file
 - Added R functions rk.save.workplace() and rk.restore.workplace() to save / restore a set of document windows
 - RKWard now tries to detect, when a workspace has been moved to a new directory, and adjust the paths restored script editor windows, accordingly
 - Fixed: Potential crashes when changing length of a data.frame that is currently opened for editing from R code
 - All pages in the package installation dialog now support sorting and keyboard search
 - Fixed: Converting from factor to string in the data editor set values to numeric, internally
 - Allow entering factor labels instead of only numbers, when editing factors in the data editor
 - Display logical values as "TRUE" and "FALSE" in data editor, and accept "T"/"TRUE"/"F"/"FALSE" in addition to "0"/"1" while editing
 - Add support for R functions loadhistory(), savehistory(), history(), and timestamp ()
 - Do not load .RData file from current directory by default (configurable)
 - Fixed: On Windows, a wrong locale for LC_NUMERIC would be applied, resulting in malfunction of pdf() and postscript()
 - Fixed: Did not use system configured background color in data editor
 - Fixed: New columns would be always be added to the right, instead of to the left, in the data editor
 - Fixed: Would crash when trying to edit 0 row data.frame
 - Fixed: Output generated by external processes (system()) was not shown on the console
 - Fixed: Converting a variable to factor in the editor would drop existing levels, silently, and lead to NAs
 - Fixed: Cursor would keep jumping to the end, when typing a filename in the filename selection field in plugins
 - Fixed: Submit button would not become enabled in "Basic Statistics" plugin
 - Moved automated testing framework moved to a dedicated R package "rkwardtests", and added documentation
 - Support pasting to the middle of the current command line in the R Console
 - Better handling of script-editor commands while the R Console is busy
 - Correct interleaving of multi-line commands and the corresponding output in the R Console
 - Fixed: Portions of multi-line commands entered on the R Console would be run twice under some circumstances
 - Fixed: Lockups or crashes when using packages RGtk2 or rJava on the X11 platform
 - Fixed: R task callback handlers were not called
 - GUI frontend and R backend now run in separate processes
 - Re-write of large portions of the R embedding code
 - Fixed: Did not respect system settings for tooltip background color in some styles
 - Fixed: Installation would continue, seemingly successfully, even if R support libraries could not be installed
 - Fixed: Function argument hints would sometimes persist after closing a script window
 - Fixed: Would fail to analyse structure of ReferenceClass-objects
 - Fixed: "Vector" mode in "Paste special" action did not work correctly
 - Attempt to save workspace on crashes
 - Also try to relay SIGABRT and SIGILL to the proper signal handlers
 - Removed the remainder of the PHP scripting backend
 - Fixed: Would crash on tcl/tk events in some cases
 
 --- Version 0.5.4 - Oct-04-2010
 - Fixed: Running user commands would crash with R 2.12.0
 - Added full-featured plot history for the onscreen graphics device
 - Fixed: Potential crash when editing data-frame with duplicate column names
 - Added option to specify default onscreen graphics dimensions
 - Fixed: Graphics windows used to assume a minimum size of 640*480 pixels, even if a smaller size was specified
 - Added option to disable function argument hinting
 - New functions rk.show.message() and rk.show.question() for user interaction from R code
 - New options for scripting GUI logic in plugins
 - The current object of an active data editor can be referenced in plugins
 - Fixed: Placement of several menu items was broken - again - with KDE 4.4 and above
 - Allow sorting of results in help search window
 - Fixed: CPU usage would go to 100% for no good reason under certain circumstances
 - The save-object selector in plugins now allows to save as part of a data.frame / list
 - Fixed: On some systems, dev.off() would spawn two new graphics windows
 - Support row names in the data.frame-editor
 - Fixed: When starting with an empty table, RKWard would sometimes claim that this object has been removed
 - Fixed: Would crash when trying to configure toolbars under certain circumstances (workaround for bug in kdelibs)
 - Fixed: Crash while analysing some objects returned by XML::xmlParseTree() for invalid XML
 - Fixed: Error while installing packages with R 2.11.0, when archiving packages in a non-existing directory
 - Added option to autosave script files (enabled by default)
 - The tabbar in the main window now shows a context menu with options to close/detach a window
 - The tabs in the main window can now be re-ordered by dragging with the mouse (left click if compiled with Qt 4.5 or above, middle click for earlier versions)
 - Added alternating row backgrounds in data.frame-editor
 
 --- Version 0.5.3 - Apr-30-2010
 - Fixed: Windows->Activate->Window left / right actions were always disabled
 - File browser window saves settings on exit
 - Several windows-specific bugs were fixed
 - Plugin dialogs are shown with a larger initial size
 - Add close buttons to each tab in the main document view area (not available in KDE 4.0)
 - Make "print", "export as HTML", "dynamic word wrap", and "increase/descress font size" available for the console window
 - Use a native menu, instead of the default TclTk-menu
 - Fixed: Newly created variables were not properly updated when closing and re-opening the editor
 - Added "paste special" action to script editor and console for pasting R vectors and matrices from spreadsheets
 - Fix order of menus for detached windows
 - File->Open R Script File now allows to specify the character encoding to use
 - Fixed: No entries were added the recent script/workspaces actions after "save as"
 - Initialize the output file with an appropriate encoding specification
 - Add SVG support to export (graphics) plugin
 - Add basic settings format settings for graphics output
 - Convert all plugins to use ECMAscript instead of PHP; RKWard no longer depends on PHP
 - Fixed: Frequent crashes while running automated plugintests
 - Fixed: Filenames without extension would not be shown in file dialogs
 - Fixed: Calling "fix(my.fun)" would remove comments
 - Fixed: Removing "@CRAN@" from the repositories would break package installation
 
 --- Version 0.5.2 - Oct-26-2009
 - Add Stata data file import plugin (by Michael Ash)
 - All directly accessible plugins now have at least one automated test
 - Add support for the dynamic help server introduced in R 2.10.0
 - Assorted minor fixes and improvements to several plugins
 - Fix deadlock while handling some Tcl events
 - Plugin dialogs close automatically after submitting (by default)
 - Fetching object structure is much faster for very large data.frames
 - Fix crash when loading certain packages on Windows
 - Fix some potential path issues on Windows
 - "Analysis" menu was restructured, slightly
 - Debug output (previously sent to stderr) is now written to a temporary file
 - On plugin help pages, display a link to invoke the plugin
 - Tolerate missing libraries in testing framework
 - Double-clicking an item in the workspace browser now opens an object viewer, or (if possible) editor
 - Safeguard against removal of essential packages via the GUI
 - Add context menu action to unload packages in the workspace browser window
 - Add shortcut to the load / unload packages dialog also in the workspace menu and the workspace browser context menu
 - Make toolbar buttons configurable
 - Fixed: Console window would sometimes remain in partially active state after piping commands
 
 --- Version 0.5.1 - Aug-04-2009
 - Support compilation on Windows
 - Add framework for automated plugin testing, and some first plugin tests
 - New command line option "--evaluate <Rcode>" mostly for the purpose of automated testing
 - Remove support for R 2.6.x and earlier
 - Add basic checks for a correct installation of the RKWard resource files
 - Remove "What to expect" dialog at startup
 - Make keyboard shorcuts configurable
 - Add option to add only single line commands from script editor to the console history
 - Add action to change working directory to that of the current script file
 - Fixed: No warning was shown, when an open script file was changed on disk, externally
 - Fixed: Opening most file types (e.g. PDF) from the help browser was broken
 - Fixed: Make built-in editor work again for file.edit ()
 - More plugins now write a header to the output window
 - Add convenience function "makeHeaderCode()" for use inside plugins
 - Adjust some icons
 - Plugins can be invoked from R code (mostly for internal purposes)
 - Add "Run again" link for plugin generated output
 - Fixed: All objects in .Globalenv would be revisited if a single object was added / removed
 - Fixed: Screen device in rkward was not seen as interactive by R
 
 --- Version 0.5.0d - May-10-2009
 - Fixed: Container of detached windows would sometimes remain after reattaching
 - Fixed: Global toolbar style was not honored
 - Fixed: Auto-scroll missing in progress dialogs and data editor
 - Fix jumping toolbar
 - Fixed: Several harmless warnings were silenced
 - Fixed: Argument hints would always stay on top regardless of focus
 - Fix crash when reaching bottom of command history in context sensitive search
 - Fix crash while inserting rows in a data.frame with string variables
 
 --- Version 0.5.0c - Mar-30-2009
 - Fix assorted installation problems
 - Updated translations: German, Spanish
 - Fix immediate crash issue with R 2.9.0 (requires recompilation against R 2.9)
 - Fixed some shortcut problems with KDElibs 4.2.x
 - Fixed: Several icons would not be loaded
 - Fix device window capturing Qt 4.4.3 (possibly other versions were broken as well)
 - Fix device window capturing with R 2.8.0
 - Extended boxplot plugin
 - Support data.frames in barplot plugin
 - New set of plugins: Item Response Theory (by Meik Michalke)
 
 --- Version 0.5.0b - Apr-20-2008
 - Support compilation with R 2.7
 - New plugin: Hodrick-Prescott Filter
 - Fix a problem with plugin help pages not loading correctly
 - Better resize handling in progress and R input (readline()) dialogs
 - Somewhat better handling of the R event loop (esp. when calling "require(not_yet_installed_package)")
 
 --- Version 0.5.0a - Jan-23-2008
 - Fixed: no objects were selectable in most varslots
 - Compilation: check for minimum kdelibs version during cmake stage
 
 --- Version 0.5.0 - Jan-21-2008
 - add support for a focus-follows-mouse activation behavior of the MDI windows (Settings->General)
 - ability to mark arbitrary "blocks" in script editor and run them with a shortcut
 - make sure that R only handles SIGSEV, when the R thread is active. Should give better backtraces and less hangs
 - object viewer was redesigned to use space better, and only fetch the print-representation when needed
 - more icons added
 - data.frame editor can be set to read-only mode
 - code completion in script editor shows icons for the different object types
 - settings dialog is now shown in "page tree" mode
 - port to KDE 4
 
 ---- KDE 3 versions
 
 --- Version 0.4.9c - Mar-18-2010
 - Backport all plugin changes and additions up to RKWard 0.5.2
 - Add support for the dynamic help server introduced in R 2.10.0
 - Backport some improvements in event handling
 - Fix deadlock while handling some Tcl events
 - Fix: Warn before saving file that was modified on disk, externally
 - Fix: Do not try to open mimetypes other than text/html directly in the help browser.
 - Fixed: Screen device in rkward was not seen as interactive by R
 
 --- Version 0.4.9b - May-10-2009
 - Workaround: Deactivate all filemanagement shortcuts in the File Browser. These would sometimes trigger when they should not.
 - Fix crash while inserting rows in a data.frame with string variables
 - Fix immediate crash issue with R 2.9.0 (requires recompilation against R 2.9)
 - Fix device window capturing with R 2.8.0
 - Extended boxplot plugin
 - Support data.frames in barplot plugin
 - New set of plugins: Item Response Theory (by Meik Michalke)
 
 --- Version 0.4.9a - Apr-20-2008
 - Support from compilation with R 2.7
 - New plugin: Hodrick-Prescott Filter
 - Fixed some lockups during startup
 
 --- Version 0.4.9 - Jan-14-2008
 - Improved user interface for CSV import plugin
 - Support drawing grids in histogram and stripchart plots
 - New plugin: Levene test
 - New plugin: Jarque-Bera test (by Germán Márquez Mejía)
 - Fixed: Crosstabs plugin produces better output
 - Fixed: use.value.labels option was wrong in SPSS import plugin
 - Fixed: SPSS tables would only be imported to the workspace, when the edit option was checked
 - Fixed: correct installation of rkward.desktop file
 - Use the KDE default fixed spacing font for command log and object viewer
 
 --- Version 0.4.8a - Nov-11-2007
 - More reliable C stack limit detection on some systems
 - Fixed: Console accepted pasted input while a command is running
 - Fixed: Analysis->Moments->Moment plugin did not use the order-parameter
 - Fixed: Crash on simple assignments in globalenv() with R < 2.4.0
 - Fixed: Meta information (labels) did not get shown correctly in the data editor
 - Add command line option "--debugger" for debugging purposes
 - Fixed: Pressing the add button in a varslot with no object selected could crash RKWard
 
 --- Version 0.4.8 - Oct-03-2007
 - New plugins: pie chart, dot chart, crosstabulation, two time-series tests, and basic linear regression
 - barplot plugin allow specification of custom labels
 - commands run through the console from the script editor will now be added to the command history (this can be turned off in the settings)
 - fixed: promise objects (created by delayedAssign()) directly in globalenv() would be forced early
 - make wrapper script work, when konsole is not installed
 - correct syntax highlighting for ::: and NA_integer_ and others
 - silence some GCC 4.2 warnings
 - fixed: crash when editing a data.frame with logicals (logicals are still mishandled, but less severe)
 - fixed: would not work with R 2.6
 - new translation: Simplified Chinese (contributed by Roy Qu)
 - more compilation fixes for GCC 4.3
 - object viewer also shows summary information, gains an update button, and MDI integration
 - CLT plugins allow drawing grid
 - add max.print option to R-Backend settings dialog
 - syntax highlighting is minimally faster for long outputs
 - graphics export plugin gains option for EPS compatibility
 - fixed: inserting / removing rows in the data editor in the presence of invalid fields in later rows would lead to a crash
 - fix some internal problems with enabledness/disabledness of plugin components
 - some complex plotting plugins now start up noticeably faster
 - fixed: sometimes detecting created X11() windows would fail, esp. under high load
 - create the workspace browser only when it is first shown
 - support for including files and snippets in xml files
 - all file selection line edits gain filename-completion
 - add a basic file selector window
 - show the focus indication (thin red border) also for detached windows
 - tool windows can be closed and detached in the same way as regular windows
 - fix a crash with detached tool windows
 - add command line option --disable-stack-check for systems where R C stack checking is buggy
 - the modifier "not" for boolean properties returns a (negated) boolean sub-propery instead of just a string
 - add possibility to blacklist packages from fetching structure information. Package GO is blacklisted by default.
 - when fetching the structure of "promise" R objects, don't keep them in memory
 - optimize the function to retrieve the structure of R objects (for display in the object browser, and completion)
 - Messages, warnings, and errors for plugin commands are shown in the output, instead of in a dialog
 
 --- Version 0.4.7a - May-07-2007
 - add sanity check for the detected stack limits
 - fixed: one some systems rkward would crash or not compile due to missing fortran symbols
 - fixed: starting the scatterplot plugin in wizard mode would crash rkward
 - tab-completion in the console will do partial completion, if all potential completions have a common start
 - fixed: file-name completion would always assume the home directory as the current directory
 - update turkish translation
 - compilation fix for FreeBSD (thanks to Thierry Thomas)
 - fixed: when executing commands line by line from the script editor, line breaks would be omitted
 
 --- Version 0.4.7 - Apr-11-2007
 - some fixes for GCC 4.3
 - fixed: the presence of user objects called "missing", "assign", or "get" would confuse some RKWard internals
 - several existing plugins have been improved in various ways
 - use maximum permissible width in the object viewer
 - fix a crash that occurred during startup under some circumstances
 - when flushing the output, also delete all graphs
 - add support for a "technical details" section in plugin help files
 - add option to enable / disable single options of a radio or dropdown control in plugins
 - t-test plugin now also allows to calculate a paired test
 - show current working directory in the statusbar
 - add run selection action to all HTML windows
 - add custom icons for run line/selection/all
 - make sure not to run parts of an incomplete user command. It would lead to all sorts of subtle problems
 - if an incomplete command was piped through the console, the console does not become blocked for piping
 - make "run current line" advance the cursor to next line after running
 - warnings and errors are highlighted in command log / console (warnings only for R >= 2.5.x)
 - plugin generated commands are run in a local() environment, allowing for more concise code
 - also support filename completion in the console (mode of completion is determined by heuristic means)
 - initial support for R's Sys.setlocale(), and encoding of CHARSXPs
 - in help files, a short title for sections (for the navigation bar) can be defined
 - the currently active window is now highlighted using a thin red border
 - fixed: changing the type of a column in the data editor was broken
 - fixed: quitting while a plugin was still active would sometimes crash rkward
 - new shortcuts for window navigation: next/previous window, activate console, activate command log, etc.
 - new functions rk.describe.alternative () and rk.print.literal () for use in plugins
 - new plugin: Phillips-Perron test
 - new plugin: Mood test
 - new plugins: CLT plots for most distributions
 - new plugins: variance tests (F test (var.test), Bartlett test, Fligner test)
 - new plugin: generic plot
 - new plugin: Add grid to plot
 - new plugin: pareto chart
 - new plugin: stem-and-leaf plot
 - make readline dialog store last size and position
 - new plugins: outlier tests (chisq.out.test, dixon.test, grubbs.test, outlier)
 - support R's mechanism for checking the C stack limits (only with R 2.3.x or greater, and not on all platforms)
 - new plugins: support of all tests from moments package
 - several new help pages
 - better error handling in PHP backend
 - fixed: depending on some buffer sizes, plugins could get stuck while generating code
 - fixed: plugin browser type="dir" would not work correctly
 - import SPSS and import CSV plugins gain option to open object for editing, automatically (checked by default)
 - warn when opening very large objects (with more than 250000 fields; this limit is configurable)
 - add a "copy" tag to facilitate writing plugins with both dialog and wizard interfaces
 - fixed: graph previews would stop working when the interface is switched from dialog to wizard or vice versa
 - new options for plugin dialogs: Configure whether code display is shown by default, and at what size
 
 --- Version 0.4.6 - Feb-15-2007
 - make sure any LC_ALL environment setting will not be applied by SCIM plugin (if installed on the system)
 - fix crash after changing storage type of an object in the data editor
 - single line input fields in plugins no longer accept new-lines
 - support for calculating p-values in correlation matrix plugin
 - fixed: pressing F8 in the console would remove input focus from the console
 - pressing tab changes focus while in a single line text input field
 - fix several small problems with detached windows
 - fix a problem with keeping the list of objects up to date
 - improvements to spinbox: step size is adjusted dynamically, and no arbitrary limits in real mode
 - fixed problem with specifying y axis limits in several plugins
 - simplified CSV import plugin
 - new plugin: import SPSS files
 - new documentation pages: console
 - various improvements to existing distribution and distribution plot plugins
 - new plugins: distribution plots: beta, binomial, cauchy, exponential, gamma, geometric, hypergeometric,
 		logistics, lognormal, negative binomail, tukey, uniform, weibull, wilcoxon
 - fixed: installing packages as root would not work, when $R_HOME is not defined
 - new plugin element to select name of an R object to save to
 - new plugin: Ansari-Bradley two-sample test
 - place internal objects .rk.rkreply and .rk.available.packages.cache into rkward package environment
 - support for preview functionality in graphing plugins
 - new plugin: barplot
 - new plugin: export contents of an X11 device to several different file formats
 - plugins can now be context sensitive (e.g. work on a particular x11 device)
 - new plugin: Wilcoxon Rank Sum test and Wilcoxon Exact Rank Sum test
 - new plugin: scatterplot matrix
 - new plugin: correlation matrix plot
 - safer destruction of R backend on quitting
 - fix compilation for the upcoming R 2.5.0
 - show full error message for syntax errors (only if compiled with R 2.4.0 or newer)
 - more correct auto-printing of values for user commands (only if compiled with R 2.4.0 or newer)
 - more correct handling of user commands consisting of several statements (only if compiled with R 2.4.0 or newer)
 - add ability to search command history context sensitively
 - add possibility to use dropdown lists in plugins
 
 --- Version 0.4.5 - Jan-21-2007
 - change shortcuts for Open/Save Workspace to Ctrl+Shift+O/S to avoid clash with Open/Save Script File
 - remove "Configure Packages" option from Workspace menu, as it is also in Settings menu
 - fixed: non-local workspaces would not be loaded
 - fixed: specifying a workspace to load on the command line would only work for full urls
 - new Console RMB actions: "copy selection cleaned" and "run selection"
 - added a basic help system, and some introductory help pages
 - added plugin for skewness and kurtosis
 - added several plugins for distribution analysis
 - added plugins for stripchart & density plot
 - enhancements to existing plot plugins
 - added refresh output and flush output as toolbar actions
 - removed the "output" menu; entries were moved to "Edit" and "View"
 - always show all top level menus
 - code generated for most plugins cleaned and simplified
 - new function rk.results () for use in plugins
 - fix: the output window would not refresh changed plot images (unless closed and reopened)
 - fix several minor issues as identified by the "krazy" source code checker
 - allow varslots to request objects of specified dimensionality and length
 - fixed: integer spinboxes with starting values greater than 1 would get unreasonable change steps
 - fix compilation with some versions of KDE / GCC
 - small improvements to syntax highlighting definition
 - in console, make cursor go to empty next line after pressing enter, before there is output (more like in the real console)
 - add "run selection" option to command log
 - script editor commands are piped through the console (by default; this is configurable)
 - assorted cleanups
 
 --- Version 0.4.2 - Dec-04-2006
 - code generated by scatterplot plugin is simplified somewhat
 - add comment headers to the sections of commands produced by plugins
 - if a user command results in the output html file to be modified, auto-refresh output
 - add RMB menu to script editor windows
 - add options "clear" and "configure" in the console RMB menu, and the command log RMB menu
 - add option to save workplace layout not per workspace, but at the end of the session
 - add options ("printcmd") to settings
 - fix help menu for detached windows
 - R X11 device windows are now managed by rkward, with the following initial features:
 - R X11 device windows: attach to / detach from workplace (they start detached)
 - R X11 device windows: toggle between normal resize mode and (settable) fixed size with scrollbars
 - R X11 device windows: menu options to copy / print / duplicate / save / activate devices
 - fixed: selecting Window->Close in a detached window would only close the internal view, not the window
 - when detaching a window, give it a more reasonable size
 - do not open the same script url twice (instead the corresponding window is raised on the second attempt)
 - fixed: when closing a detached script editor window, you would not be asked to save changes (if any)
 - fixed: occasional crash when re-attaching a script editor window
 - new translations: Greek, Catalan
 - updated translations: German, French
 - added basic plot facility for ECDF (Empirical Cumulative Distribution Function) (menu plots)
 - added ptukey and qtukey (Studentized Range Distribution (Tukey)) (menu distributions)
 - spelling corrections in distributions menu
 - reorganized "Descriptive Statistics" plugin to use tabs for better usability
 - added constant for mad in descriptive statistics plugin
 - fix bug in rk.get.label ()
 - in script editor, do not provide symbol name completion while in comments
 - properly support active bindings in globalenv ()
 - if not started in a tty, spawn a konsole. R will go into non-interactive mode otherwise
 
 --- Version 0.4.1 - Nov-05-2006
 - allow specification of title/subtitle in plot options plugin (currently used by boxplot, and histogram)
 - fix bug in beta probabilities plugin
 - fix (some?) compilation problems with KDE 3.2
 - when packages have been newly installed, show them in the load / unload packages tab immediately
 - fix to plugin input lines sizing, and visibility of scrollbars
 - on startup, show window maximized if no size stored (i.e. very first startup)
 - prevent infinite recursion when parsing structure of environments
 - fix for compilation on 64bit architectures
 - remove misleading "About KDE" dialog, and replace report Bug dialog with correct information
 - don't crash when closing a detached window
 - function argument hinting in the console and script editor
 - as you type completion of R symbol names in the script editor
 - tab completion of R symbol names in the console
 - added R function rk.edit (x) to open object x for editing in rkward
 - fixed: an empty table created before the object list was updated (esp. at startup) would be thought to have been removed in the workspace
 - object data changed in the console (or by other means) is updated to the editor automatically, if the object is opened for editing
 - fixed: back / forward buttons would sometimes remain after closing a help window
 - fix some focus problems
 - provide close buttons in tab bar
 
 --- Version 0.4.0 - Oct-17-2006
 - many new distribution plugins
 - all distribution plugins now use a free-text field, allowing you to enter a vector of probabilties / quantiles
 - another fix to cancelling during readline () calls
 - invalid values are stored in a separate attribute instead of changing the storage mode back and forth
 - storage mode for RKWard meta data was changed
 - RMB option to search help on objects from packages in object browser
 - show tooltip information on objects in object browser
 - do not crash on call to "browser ()"
 - the object browser is updated automatically when needed
 - allow some more configuration in object browser
 - include all package environments in object list
 - use more efficient data passing to synchronize object list
 - add (ugly) items for functions and lists to object browser
 - internal cleanups (partially to make porting to KDE4/Qt4 easier)
 - when saving/loading the workspace, save / restore all windows (not just data editors)
 - remember workspace url after save as
 - fix a long standing (but hard to trigger) crash while closing data editor window
 - fix "Open R Script File" filename ending filter
 - add mismatching brace detection to syntax highlighting
 - yet another crash on more than 100 rows bug fixed
 - RKWard should now be fully UTF-8 aware. All characters are passed to and from R reliably
 
 --- Version 0.3.7 - Sep-17-2006
 - added Turkish translation
 - avoid lockups when cancelling a readline ()
 - show output context (if any) when the backend asks for input via readline ()
 - link against libRblas.so if it is found in the R libs dir (needed for some compiles of R 2.4.0)
 - remove whitespace from start and end of plugin generated commands and do not evaluate empty commands
 - do not raise the command log more than once for a given command producing continuous output
 - small improvements to command history in console
 - deal better with commands producing large amounts of output
 - small fixes in several plugins
 - package installation/update: semi-automate package installation in response to "require ()" calls
 - package installation/update: the online list of available packages is cached up to one hour (and only as long as the relevant options are unchanged)
 - package installation/update: give better progress indication
 - package installation/update: package dependencies are handled correctly when installating new packages
 - package installation/update: packages can be installed to custom library locations
 - fix spurious line breaks in output in command log and console
 - Improved syntax highlighting defintion including code folding
 - fix compilation with GCC 4.1
 - don't crash on more than 100 rows of data in the editor (off by 2 bug in storage allocation)
 - correctly initialize the internal NaN representation (would sometimes be initialized to 0, resulting in 0s not to be shown in the editor)
 - engine status bar label ("R engine busy/idle") now changes background color according to state
 - honor DESTDIR setting while installing rkward R package, and add configure option --with-r-libdir
 - only link against -lRlapack, if that is available
 - commands producing lots of output would sometimes be impossible to interrupt. Fixed
 - show command output immediately in command log
 - remember location where R script/workspace files were last opened, and start file-selection dialogs there
 - sometimes the last level in the factor levels editor got lost. Fixed
 
 --- Version 0.3.6 - Apr-23-2006
 - several fixes to the distributions plugins
 - remove debian dir from source distribution again
 - remove one level of menu nesting for save/load R Objects plugins
 - check for and handle some strange R parse errors that could crash rkward
 - make Ctrl+C copy work in the code window of plugins
 - use KDE standard icons in object lists (need to be replaced by customized icons in the long run)
 - don't try to show higher numeric precision than is actually available
 - fix bug in scatterplot plugin
 - remove configure options --with-r-share and --with-r-doc (obsoleted by improved wrapper script)
 - allow deletion of several rows at once in the data.frame editor and fix some bugs regarding deletion of rows
 - prevent R-Object listviews (Varselector, Workspace Browser) from growing excessively wide
 - make Ctrl+V work in the console
 - middle mouse pastes selection, not global clipboard in the console, as expected
 - clean up output of require (quietly=FALSE)
 - some fixes for R 2.3.0
 - pressing Cancel in readline ("R backend requests information") dialog interrupts the command
 - process R X11 events while modal dialogs (such as "R backend requests information") are shown
 - allow empty input in readline ("R backend requests information") dialog
 - make Ctrl+C/copy work in output and help windows
 
 --- Version 0.3.5 - Apr-16-2006
 - give back focus to the script editor after running line/selection/all
 - reworded exit dialog box
 - show info message, if retrieving context help fails
 - pressing Ctrl+C in the console resets a partial command, if any
 - added syntax highlighting in the console
 - configure: if not overriden, and $KDEDIR is not set, assume --prefix=`kde-config --prefix` instead of /usr/local/kde/
 - remove some GUI clutter for Script File editor
 - rename "Command File" to "Script File"
 - rename "Command Stack" window to "Pending Jobs"
 - backspace or del clear cells in data.frame editor
 - reworked factor levels editor
 - in trailing rows/columns of the data.frame editor, change background color, when selected
 - explicitely set LC_NUMERIC to "C" at startup. R does not work correctly with other settings of LC_NUMERIC
 - many new plugins by Stefan Roediger
 - clean up R temporary files on shutdown
 - when switching between dialog and wizard interfaces, GUI settings are copied
 - fix crash with objects with quotes in their names
 - add options to show help-search and R help index to Help menu
 - complete rework of plugins code
 - plugins can embed other plugins
 - code display (for plugins) gets updated reliably
 - avoid leftover PHP processes if rkward crashes or gets killed
 - autodetection of R_HOME and related variables during configure
 - fix status bar
 - handle non-existing and non-local URLs (links) in help window
 - use a shell wrapper around rkward to do some setup just like R. This should fix a number of minor quirks
 - configure: use single configure option for location of R_HOME, and add check for libR.so
 - yet more code cleanups
 - keep main window caption up to date
 - update tab caption for command editor if filename changes (i.e. saved as)
 - indicate if a document in a command editor is modified (unsaved)
 
 --- Version 0.3.4 - Nov-08-2005
 - assorted bugfixes
 - include debian-dir in source distribution
 - real time display of command output in the console
 - automatically scroll command log to the bottom when new lines are added
 - less verbose output in command log (removed "issuing command", etc.)
 - use KXMLGUI for placing plugins in the menu (mostly an internal change, but menu placement should remain sane, when active window changes, now)
 - help-, output-, and editor-views can be detached to separate windows
 - allow to bypass startup dialog
 - back/forward navigation in help pages
 - can print help pages and output
 - better handling of errors while installing packages
 - limit number of lines to display in console and command log (user setting)
 - remove menu clutter from help window, and output window
 - avoid adding incomplete (multi-line) Console commands to the Command Log
 - Settings->Command Log->show/raise window working again
 - allow loading/saving of command history (console commands)
 - add (meaningful) context menu for console
 - allow interrupting current command running in the console via Ctrl+C
 - add "Command stack" window for advanced control of R backend (cancel commands, pause chain, view stack)
 - modifiy rkward.desktop to always start rkward in a terminal. The backend sometimes behaves strangely, if this is not done.
 - use available.packages instead of CRAN.packages (deprecated in R 2.2.0)
 - fix installation of standard_plugins.pluginmap
 - allow configuration of many R options in Settings->R backend
 - updated French translation
 - make "up"-button work in R-backend repository settings
 - more code cleanups
 
 --- Version 0.3.3 - Oct-06-2005
 - honor debug-level setting everywhere
 - reworked handling of output from R (no more file-sinks)
 - fix display of warning messages (behavior does not match plain R, yet, but is mostly sane)
 - option to change list of package repositories
 - option to archive downloaded packages
 - assorted bugfixes
 - provide context/function help for the console
 - output-window has been switched to KPart-infrastructure
 - command-editor has been switched to KPart-infrastructure completely
 - data-editor uses KPart-infrastructure (better integration)
 - override standard callbacks used by R for ReadConsole, ShowFiles, EditFile(s), ChooseFile, Suicide, CleanUp. No more reliance on stdin
 - some cleanups of dead code
 - plugins can now be placed in different menus
 - keep list of components/plugins and menu-hierarchy in (few) .pluginmap files instead of parsing directory structure
 - improved handling of tcltk windows
 - new icon
 - decrease default debug level
 - don't crash when objects change their type from vector to list/data.frame, etc.
 - graph-creation no longer relies on (removable) R objects (can graph after loading a workspace)
 
 --- Version 0.3.2 - Apr-27-2005
 - overloaded require works properly with character.only=FALSE
 - several API documentation improvement
 - hidden objects get shown/hidden according to configuration setting
 - settings dialog honors KDE-button order
 - R's x11 windows now handle their events (x11-device is now usable)
 - fixed bug in the output (no update on empty output)
 - paste in the console is properly handled
 - r console and command log divorced
 - console can handle incomplete statements (allowing multi-line input)
 - fixed silly crash on incomplete statements
 - updated spanish translation
 - new plugin (graph)
 - reworked the interface to use kparts properly
 
 --- Version 0.3.1 - Mar-26-2005
 - added the possibility to unable widget in plugins.
 - added a new plugin (basic statistics)
 - added icons in the object browser
 - using IDEAI dock mode style
 - new, console-like widget to enter commands manually.
 - added a class to show html help in an mdi child
 - added a new dock to search R help
 - many changes in labels
 - fixed: bug that prevented RKWard to build on some systems
 - added R functions to show graphs in the html output and to print objects (using E. Lecoutre's R2HTML)
 - use a KHTML part to show output (instead of the qt widget)
 
 --- Version 0.3.0 - Nov-12-2004
 - added french and italian translations
 - added toolbars and some icons
 - some small i18n fixes
 - rework of user interface (now using KMDI and IDEAl mode)
 - compilation fix for R 2.0
 - added basic per variable formatting options in the data editor (alignment, precision)
 - fixed: cell last edited did not react to single mouse click
 - fixed: switched to line below after a new row was automatically added
 - fixed: cursor right did not move to next cell when editing last (active) column
 - while editing, tab-key moves to next cell
 
 --- Version 0.2.9 - Sep-22-2004
 - use KDialog::marginHint () and KDialog::spacingHint () in plugins
 - fixed a crash in the formula widget
 - converted plugin element to QWidgets (in preparation for more extensive rework of plugin elements)
 - almost complete rework of data editor
 - added edit support for factors
 - added support for editing factor levels
 - data editor stores data more efficiently
 - renaming columns in a data.frame does not change their position in the frame
 - recursively remove children of removed objects (fixes one of probably many memory leaks)
 - wait for backend-thread to terminate on exit. Avoids crashes when closing RKWard
 - do not crash if loading the "rkward" R package fails, but rather display a nice error-message
 
 --- Version 0.2.8 - Sep-09-2004
 - override for require () to show install-packages dialog, if required package is not installed.
 - Dialog to load/unload packages, update and install packages from CRAN
 - added capability to cancel commands (not properly integrated in the GUI, yet)
 - basic name checking for objects added or renamed by the user
 - remove uneccessary blank are below menu in R-Console window
 - fix R process busy/idle display
 - show error message if loading workspace fails
 - do not ask for save, if workspace is empty
 - results of user-commands get printed if not invisible (i.e. just like in a regular R session)
 - provide at least basic feedback on syntax errors
 - added communication channel from R-backend to RKWard. Initial features:
 	- checking for errors setting up the connection
 	- simple rk.sync for synchronisation of objects modified in the R workspace
 	- rk.get.tempfile.name for generation of a suitable temporary file (e.g. for storing images)
 	- allows for in-place execution of commands or scheduling of commands in the regular stack
 - auto addition of rows/columns when typing on last row/column
 - allow deletion of rows without losing meta-data
 
 --- Version 0.2.7 - Sep-02-2004
 - several compilation fixes for KDE/Qt < 3.2.x (and maybe some new ones were introduced?)
 - slight reorganization of menus
 - added menu option to close all editor windows
 - some improvements in the editing behavior for the table. Some quirks still present
 - renamed windows
 - fixed some typos
 - set initial minimum sizes for object browser and object viewer windows
 - don't show all windows on startup
 - ask whether to save current workspace before loading a new one
 - added command-line option to set, which components to show debug-messages for
 - added option(s) to show/raise watch-window when new commands get displayed
 - formula-widget handles multiple table situation correctly
 - RKVarselector and RKObjectBrowser use a common base class for the list view
 - RKVarselector and dependent widgets get updated when objects get added/removed/modified
 - prevent conversion to factors when creating data.frames for now
 - variables can be added/removed correctly in the data.frame editor. Those changes are propagated to the RObjectBrowser automatically
 - synchronisation from the GUI to the R-workspace is done immediately
 - added ability to spawn separate command-editor window(s) with load/save/print/etc.
 - command-editor part in the watch-window keeps keyboard focus (most of the time)
 
 --- Version 0.2.6a - Aug-30-2004
 - synchronize edited objects before "View"ing them
 - fix small typo
 - quick-and-dirty fix for problem with objects in a new table (e.g. "my.data") never getting synced
 
 --- Version 0.2.6 - Aug-29-2004
 - added error-handling to workspace saving
 - ask whether to save workspace on application quit
 - added menu-entries to clear output-window and watch-log
 - don't duplicate menu-entries when plugins get re-scanned
 - place "Analyse"-menu left of help-menu
 - converted plugins to rely entirely on R for formatting, i.e. the printout ()-section contains pure R-code only
 - wizard-interface is set as default for plugins
 - added access to kate-config dialog in the command-editor part of the interface watch
 - added configuration settings for which types of commands to show in the interface watch
 - added a nice startup-dialog instead of creating an emtpy table unconditionally
 - limit size of upper-half in the data.frame editor
 - added convenience R-library: used to streamline communication with R
 - fix against data being synced over and over again
 
 --- Version 0.2.5 - Aug-24-2004 ---
 - added simple viewer for R-objects
 - added simple browser for objects in the R-workspace
 - allow deletion of columns/objects (finally)
 - allow editing and using several objects/tables
 - added command-line parameter "debug-level"
 - interpret command-line parameter "file"
 - save and restore size of the main window correctly
 - use internal representation of object-tree in the R-workspace
 - store meta-information (labels, etc.) as R-attributes
 - keep track of whether the windows (watch, output) are open
 - new method of access to objects in R: getIntVector
 - use some "global" static pointers instead of passing them around (e.g. for the r-interface)
 - reorganized sources: now using subdirectories for most components
 
 --- Version 0.2.2 - Aug-15-2004 ---
 - added an improved kate syntax-highlighting definition for R
 - output-formatting is done in R instead of PHP
 - added a formula widget for use in plugins (not entirely finished, yet)
 - fixed some small compilation problems
 - added spinbox widget for use in plugins
 - use coloring for "unsatisfied" plugin widgets instead of the "Problems" display
 - added support for wizard-like plugins
 - same plugin can be opened several times at once
 - use katepart for plugin code view, too
 
 --- Version 0.2.1 - Aug-08-2004 ---
 - added "don't show again" setting to initial warning
 - added correlation matrix plugin
 - ask for R_HOME-setting if not availalbe at startup
 - allow direct (read) access of vectors in R
 - support for selection of multiple variables at once
 - use a katepart as the command-editor (provides basic syntax-highlighting)
 - plugins can use a tabbook-layout
 - display status of R-process in the statusbar
 - R-backend allows chains of commands that are guaranteed to be run without other intermitting commands
 - run R in a separate thread
 
 --- Version 0.2.0 - Aug-01-2004 ---
 - Use a PHP-backend for the plugins
 - Run R embedded (currently synchronous)
 - Some changes in plugin-creation
 - Use pretty HTML-output
 - got rid of ui-files
 - added descriptive statistics plugin
 - lots of small changes I didn't document properly
 
 --- Version 0.1.0 - Nov-19-2002 ---
 - Initial features:
 - A simple backend-interface communicating with R via stdin/stdout
 - Asynchronous command stack
 - A simple window for watching communication with R
 - Ability to issue commands manually
 - Editor window including meta information on the variables
 - Copy-and-Paste with some quirks
 - highlighting of invalid data
 - load/save of R-workspace (load only works for RKWard data)
 - Automatic generation of menu-structure and plugin-dialogs from XML-files
 - Supported plugin widgets: textfield, variable-selector, variable-slot, radiobuttons
 - independent samples t-test plugin
diff --git a/doc/rkwardplugins/index.docbook b/doc/rkwardplugins/index.docbook
index 0a7458fe..e7afbc45 100644
--- a/doc/rkwardplugins/index.docbook
+++ b/doc/rkwardplugins/index.docbook
@@ -1,4570 +1,4574 @@
 <?xml version="1.0" ?>
 <!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd" [
   <!ENTITY rkward '<application>RKWard</application>'>
   <!ENTITY r '<application>R</application>'>
   <!ENTITY pluginmap '<literal role="extension">.pluginmap</literal>'>
   <!ENTITY kapp "&rkward;"><!-- replace rkward here -->
   <!ENTITY % addindex "IGNORE">
   <!ENTITY % English "INCLUDE"><!-- change language only here -->
   
   
   <!-- Do not define any other entities; instead, use the entities
        from kde-genent.entities and $LANG/user.entities. -->
 ]>
 
 <book lang="&language;">
 
 <!-- This header contains all of the meta-information for the document such
 as Authors, publish date, the abstract, and Keywords -->
 
 <bookinfo>
 <title>Introduction to Writing Plugins for RKWard</title>
 
 <authorgroup>
 <author>
 <firstname>Thomas</firstname>
 <surname>Friedrichsmeier</surname>
 <affiliation>
 <address><email>rkward-devel AT kde DOT org</email></address>
 </affiliation>
 </author>
 
 <author>
 <firstname>Meik</firstname>
 <surname>Michalke</surname>
 <affiliation>
 <address><email>rkward-devel AT kde DOT org</email></address>
 </affiliation>
 </author>
 <!-- Additional authors go here -->
 
 <!-- TRANS:ROLES_OF_TRANSLATORS -->
 </authorgroup>
 
 
 
 <copyright>
 <year>2006</year>
 <year>2007</year>
 <year>2008</year>
 <year>2010</year>
 <year>2011</year>
 <year>2012</year>
 <year>2013</year>
 <year>2014</year>
 <year>2015</year>
 <holder>Thomas Friedrichsmeier</holder>
 </copyright>
 <!-- Translators: put here the copyright notice of the translation -->
 <!-- Put here the FDL notice.  Read the explanation in fdl-notice.docbook 
      and in the FDL itself on how to use it. -->
 <legalnotice>&FDLNotice;</legalnotice>
 
 <date>2015-11-05</date>
 <releaseinfo>0.6.400</releaseinfo>
 
 <abstract>
 <para>
 This is a guide to writing plugins for &rkward;.
 </para>
 </abstract>
 
 <keywordset>
 <keyword>KDE</keyword>
 <keyword>R</keyword>
 <keyword>rkward</keyword>
 <keyword>plugins</keyword>
 </keywordset>
 
 </bookinfo>
 
 <chapter id="introduction">
 <title>Introduction</title>
 
 	<note>
 		<para>
 			Documentation as of &rkward; release 0.6.4.
 		</para>
 	</note>
 	<para>
 		This document describes how to write your own plugins. Note, that at the time of this writing, some of the concepts are not yet set it stone. Therefore, this document should be regarded as an introduction to the current approach, and as a basis for discussion. All sorts of comments are welcome.
 		The documentation has grown quite large over time. Don't let that scare you. We recommend reading through the four basic steps (as
 		outlined, below), to get a basic idea of how things work. After that you may want to skim the table of contents to see which advanced
 		topics could be of relevance to you.
 	</para>
 	<para>
 		For questions and comments, please write to the &rkward; development mailing list.
 	</para>
 	<para>
 		<emphasis>You do not need to read this in order to use &rkward;.</emphasis> This document is about extending &rkward;. It is targeted at advanced users, or people willing to help improve &rkward;.
 	</para>
 	<para>
 		Writing a standard plugin is basically a four-step process:
 		<itemizedlist>
 			<listitem><para><link linkend="pluginmap">Placing a new Action in the menu hierarchy</link></para></listitem>
 			<listitem><para><link linkend="mainxml">Describing the looks and behavior of the plugin GUI</link></para></listitem>
 			<listitem><para><link linkend="jstemplate">Defining, how R-code is to be generated from the settings, the user makes in the GUI</link></para></listitem>
 			<listitem><para><link linkend="pluginhelp">Adding a help page to your plugin</link></para></listitem>
 		</itemizedlist>
 		Those will be dealt with in turn.
 	</para>
 	<para>
 		Some advanced concepts may be used in those four steps, but are dealt with in separate chapters, to keep things simple:
 		<itemizedlist>
 			<listitem><para><link linkend="logic">GUI logic</link></para></listitem>
 			<listitem><para><link linkend="embedding">Embedding Plugins into Plugins</link></para></listitem>
 			<listitem><para><link linkend="plugin_series">Useful concepts for creating many series of similar plugins</link></para></listitem>
 		</itemizedlist>
 	</para>
 	<para>
 		Also, none of the chapters shows all options, but rather only the basic concepts. A complete <link linkend="reference">reference</link> of options is provided separately.
 	</para>
 </chapter>
 
 <chapter id="whatareplugins">
 <title>Preliminaries: What are plugins in &rkward;? How do they work?</title>
 	<para>
 		Of course the first question you might have is: What portions of &rkward; functionality is realized using plugins? Or: What can plugins do?
 	</para>
 	<para>
 		One way to answer this is: Deselect all &pluginmap; files under <menuchoice><guimenu>Settings</guimenu><guimenuitem>Configure &rkward;</guimenuitem><guimenuitem>Plugins</guimenuitem></menuchoice>, and see what's missing. A slightly more helpful answer: Most actual statistics functions accessible via the GUI are realized using plugins. Also, you can create fairly flexible GUIs for all kinds of operations using plugins.
 	</para>
 	<para>
 		The basic paradigm behind &rkward; plugins is the one we'll walk you through in this document: An XML file describes what the GUI looks like. An additional JavaScript file is used to generate &r; syntax from the GUI settings. That is, plugins do not really have to perform any statistical calculations. Rather plugins generate the &r; syntax needed to run those calculations. The &r; syntax is then sent to the &r; backend for evaluation, and typically a result is shown in the output window.
 	</para>
 	<para>
 		Read on in the next chapters to see how this is done.
 	</para>
 </chapter>
 
 <chapter id="pluginmap">
 <title>Creating menu entries</title>
 	<para>
 		When you create a new plugin, you need to tell &rkward; about it. So the first thing to do, is to write a &pluginmap; file (or modify an existing one). The format of &pluginmap; is XML. I'll walk you through an example (also of course, be sure you have &rkward; configured to load your &pluginmap; -- <menuchoice><guimenu>Settings</guimenu><guimenuitem>Configure &rkward;</guimenuitem><guimenuitem>Plugins</guimenuitem></menuchoice>):
 	</para>
 	<tip>
 		<para>
 			After reading this chapter, have a look at the <link linkend="rkwarddev"><application>rkwarddev</application> package</link> as well. It provides some &r; functions to create most of &rkward;'s XML tags for you.
 		</para>
 	</tip>
 	<programlisting>
 &lt;!DOCTYPE rkpluginmap&gt;
 	</programlisting>
 	<para>
 	The doctype is not really interpreted, but set it to <replaceable>"rkpluginmap"</replaceable> anyway.
 	</para>
 	<programlisting>
 &lt;document base_prefix="" namespace="myplugins" id="mypluginmap"&gt;
 	</programlisting>
 	<para>
 		The <parameter>base_prefix</parameter> attribute can be used, if all your plugins reside in a common directory. Basically, then you can omit that directory from the filenames specified below. It safe to leave this at <replaceable>""</replaceable>.
 	</para><para>
 		As you will see below, all plugins get a unique identifier, <parameter>id</parameter>. The <parameter>namespace</parameter> is a way to organize those IDs, and make it less likely to create a duplicate identifier accidentally. Internally, basically the namespace and then a <quote>::</quote> gets prepended to all the identifiers you specify in this &pluginmap;. In general, if you intend to <link linkend="sect_external_plugins">distribute your plugins in an R package</link>, it is a good idea to use the package name as <parameter>namespace</parameter> parameter. Plugins shipped with the official &rkward; distribution have <replaceable>namespace="rkward"</replaceable>.
 	</para>
 	<para>
 		The <parameter>id</parameter> attribute is optional, but specifying an id for your &pluginmap; makes it possible for other people to make their &pluginmap;s load your &pluginmap;, automatically (see <link linkend="chapter_dependencies">the section on dependencies</link>).
 	</para>
 	<programlisting>
 	&lt;components&gt;
 	</programlisting>
 	<para>
 		Components? Aren't we talking about plugins? Yes, but in the future, plugins will be no more than a special class of components. What we do here, then, is to register all components/plugins with &rkward;. Let's look at an example entry:
 	</para>
 	<programlisting>
 		&lt;component type="standard" id="t_test_two_vars" file="t_test_two_vars.xml" label="Two Variable t-Test" /&gt;
 	</programlisting>
 	<para>
 		First the <parameter>type</parameter> attribute: Leave this to <replaceable>"standard"</replaceable> for now. Further types are not yet implemented. The <parameter>id</parameter> we've already hinted at. Each component has to be given a unique (in its namespace) identifier. Pick one that is easily recognizable. Avoid spaces and any special characters. Those are not banned, so far, but might have special meanings. With the <parameter>file</parameter> attribute, you specify where the <link linkend="mainxml">description of the actual plugin itself</link> is located. This is relative to the directory the &pluginmap; file is in, and the <parameter>base_prefix</parameter> above. Finally, give the component a label. This label will be shown wherever the plugin is placed in the menu (or in the future perhaps in other places as well).
 	</para>
 	<para>
 		Typically a &pluginmap; file will contain several components, so here are a few more:
 	</para>
 	<programlisting>
 		&lt;component type="standard" id="unimplemented_test" file="means/unimplemented.xml" /&gt;
 		&lt;component type="standard" id="fictional_t_test" file="means/ttests/fictional.xml" label="This is a fictional t-test" /&gt;
 		&lt;component type="standard" id="descriptive" file="descriptive.xml" label="Descriptive Statistics" /&gt;
 		&lt;component type="standard" id="corr_matrix" file="corr_matrix.xml" label="Correlation Matrix" /&gt;
 		&lt;component type="standard" id="simple_anova" file="simple_anova.xml" label="Simple Anova" /&gt;
 	&lt;/components&gt;
 	</programlisting>
 	<para>
 		Ok, this was the first step. &rkward; now knows those plugins exist. But how to invoke them? They need to be placed in a menu hierarchy:
 	</para>
 	<programlisting>
 	&lt;hierarchy&gt;
 		&lt;menu id="analysis" label="Analysis"&gt;
 	</programlisting>
 	<para>
 		Right below the <command>&lt;hierarchy&gt;</command> tag, you start describing, in which <command>&lt;menu&gt;</command> your plugins should go. With the above line, you basically say, that your plugin should be in the <menuchoice><guimenu>Analysis</guimenu></menuchoice> menu (not necessarily directly there, but in a submenu). The <menuchoice><guimenu>Analysis</guimenu></menuchoice> menu is standard in &rkward;, so it does not actually have to be created from scratch. However, if it did not exist yet, using the <parameter>label</parameter> attribute you'd give it its name.
 		Finally, the <parameter>id</parameter> once again identifies this <command>&lt;menu&gt;</command>. This is needed, so several &pluginmap; files can place their plugins in the same menus. They do this by looking for a <command>&lt;menu&gt;</command> with the given <parameter>id</parameter>. If the ID does not yet exist, a new menu will be created. Otherwise the entries will be added to the existing menu.
 	</para>
 	<programlisting>
 			&lt;menu id="means" label="Means"&gt;
 	</programlisting>
 	<para>
 		Basically the same thing here: Now we define a submenu to the <menuchoice><guimenu>Analysis</guimenu></menuchoice> menu. It is to be called <menuchoice><guimenuitem>Means</guimenuitem></menuchoice>.
 	</para>
 	<programlisting>
 				&lt;menu id="ttests" label="t-Tests"&gt;
 	</programlisting>
 	<para>
 		And a final level in the menu hierarchy: A submenu of the submenu <menuchoice><guimenuitem>Means</guimenuitem></menuchoice>.
 	</para>
 	<programlisting>
 					&lt;entry component="t_test_two_vars" /&gt;
 	</programlisting>
 	<para>
 		Now, finally, this is the menu we want to place the plugin in. The <command>&lt;entry&gt;</command> tag signals, this actually is the real thing, instead of another submenu. The <parameter>component</parameter> attribute refers to the <parameter>id</parameter> you gave the plugin/component above.
 	</para>
 	<programlisting>
 					&lt;entry component="fictional_t_test" /&gt;
 				&lt;/menu&gt;
 				&lt;entry component="fictional_t_test" /&gt;
 			&lt;/menu&gt;
 			&lt;menu id="frequency" label="Frequency" index="2"/&gt;
 	</programlisting>
 	<para>
 		In case you have lost track: This is another submenu to the <menuchoice><guimenu>Analysis</guimenu></menuchoice> menu. See the screenshot below. We'll skip some of what's not visible, marked with [...].
 	</para>
 	<programlisting>
 				[...]
 			&lt;/menu&gt;
 			&lt;entry component="corr_matrix"/&gt;
 			&lt;entry component="descriptive"/&gt;
 			&lt;entry component="simple_anova"/&gt;
 		&lt;/menu&gt;
 	</programlisting>
 	<para>
 		These are the final entries visible in the screenshots below.
 	</para>
 	<programlisting>
 		&lt;menu id="plots" label="Plots"&gt;
 			[...]
 		&lt;/menu&gt;
 	</programlisting>
 	<para>
 		Of course you can also place your plugins in menus other than <menuchoice><guimenu>Analysis</guimenu></menuchoice>.
 	</para>
 	<programlisting>
 		&lt;menu id="file" label="File"&gt;
 			[...]
 		&lt;/menu&gt;
 	</programlisting>
 	<para>
 		Even in standard-menus such as <menuchoice><guimenu>File</guimenu></menuchoice>. All you need is the correct <parameter>id</parameter>.
 	</para>
 	<programlisting>
 	&lt;/hierarchy&gt;	
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		That's how to do it. And this screenshot shows the result:
 	</para>
 	<screenshot>
 	<screeninfo>Menu hierarchy created by the code shown above</screeninfo>
 		<mediaobject>
 		<imageobject>
 			<imagedata fileref="menu_hierarchy_example.png" format="PNG"/>
 		</imageobject>
 		<textobject>
 			<phrase>Menu hierarchy created by the code shown above</phrase>
 		</textobject>
 		</mediaobject>
 	</screenshot>
 	<para>
 		Confused? The easiest way to get started is probably taking some of the existing &pluginmap; files shipped with the distribution, and modifying them to your needs. Also, if you need help, don't hesitate to write to the development mailing list.
 	</para>
 	<sect1 id="pluginmap_grouping"><title>Controlling the order of menu entries</title>
 		<para>By default, all items (entries / submenus) inside a menu will be sorted alphabetically, automatically. In <emphasis>some</emphasis> cases you may want more control. In this case you can group elements as follows:</para>
 		<itemizedlist>
 			<listitem>
 				<para>You can define groups inside any menu like this. All elements belonging to the same group will be grouped together:</para>
 				<programlisting>
 		&lt;group id="somegroup"/&gt;
 				</programlisting>
 			</listitem><listitem>
 			<para>If you want the group to be visually separated from other entries, use:</para>
 				<programlisting>
 		&lt;group id="somegroup" separated="true"/&gt;
 				</programlisting>
 			</listitem><listitem>
 				<para>Entries, menus, and groups can be appended to a specified group, using:</para>
 				<programlisting>
 		&lt;entry component="..." group="somegroup"/&gt;
 				</programlisting>
 			</listitem><listitem>
 				<para>In fact, it is also possible to define groups (without separator lines) implicitly:</para>
 				<programlisting>
 		&lt;entry component="first" group="a"/&gt;
 		&lt;entry component="third"/&gt;
 		&lt;entry component="second" group="a"/&gt;
 				</programlisting>
 			</listitem><listitem>
 				<para>Group names are specific to each menu. Group "a" in menu "Data" does not conflict with group "a" in menu "Analysis", for example.</para>
 			</listitem><listitem>
 				<para>The most common use case is defining groups at the top, or at the bottom of a menu. For this, there are pre-defined groups "top" and "bottom" in each menu.</para>
 			</listitem><listitem>
 				<para>Entries within each group are sorted, alphabetically. Groups appear in the order of declaration (unless appended to another group, of course).</para>
 			</listitem><listitem>
 				<para>Menus and entries without group specification logically form a group (""), too.</para>
 			</listitem>
 		</itemizedlist>
 	</sect1>
 </chapter>
 
 <chapter id="mainxml">
 <title>Defining the GUI</title>
 <sect1 id="sect_defining_the_GUI"><title>Defining a dialog</title>
 	<para>
 		In the <link linkend="pluginmap">previous chapter</link> you've seen how to register a plugin with &rkward;. The most important ingredient was specifying the path to an XML file with a description of what the plugin actually looks like. In this chapter you'll learn how to create this XML file.
 	</para>
 	<tip>
 		<para>
 			After reading this chapter, have a look at the <link linkend="rkwarddev"><application>rkwarddev</application> package</link> as well. It provides some &r; functions to create most of &rkward;'s XML tags for you.
 		</para>
 	</tip>
 	<para>
 		Once again we'll walk you through an example. The example is a (slightly simplified) version of the two variable t-Test.
 	</para>
 	<programlisting>
 &lt;!DOCTYPE rkplugin&gt;
 	</programlisting>
 	<para>
 		The doctype is not really interpreted, yet. Set it to <replaceable>rkplugin</replaceable>, anyway.
 	</para>
 	<programlisting>
 &lt;document&gt;
 	&lt;code file="t_test_two_vars.js"/&gt;
 	</programlisting>
 	<para>
 		All plugins generate some code. Currently the only way to do so is using JS, as detailed in <link linkend="jstemplate">the next chapter</link>. This defines, where to look for the JS code. The filename is relative to the directory the plugin XML is in.
 	</para>
 	<programlisting>
 	&lt;help file="t_test_two_vars.rkh"/&gt;
 	</programlisting>
 	<para>
 		It is usually a good idea to also provide a help page for your plugin. The filename of that help page is given, here, relative to the directory, the plugin XML is in. Writing help pages is documented <link linkend="pluginhelp">here</link>. If you do not provide a help file, omit this line.
 	</para>
 	<programlisting>
 	&lt;dialog label="Two Variable t-Test"&gt;
 	</programlisting>
 	<para>
 		As you know, plugins may have either a dialog or a wizard interface or both. Here we start defining a dialog interface. the <parameter>label</parameter> attribute specifies the caption of the dialog.
 	</para>
 	<programlisting>
 		&lt;tabbook&gt;
 			&lt;tab label="Basic settings"&gt;
 	</programlisting>
 	<para>
 		GUI elements can be organized using a tabbook. Here we define a tabbook as the first element in the dialog. Use <command>&lt;tabbook&gt;</command>[...]<command>&lt;/tabbook&gt;</command> to define the tabbook and then for each page in the tabbook use <command>&lt;tab&gt;</command>[...]<command>&lt;/tab&gt;</command>. The <parameter>label</parameter> attribute in the <command>&lt;tab&gt;</command> element allows you to specify a caption for that page of the tabbook.
 	</para>
 	<programlisting>
 				&lt;row id="main_settings_row"&gt;
 	</programlisting>
 	<para>
 		The <command>&lt;row&gt;</command> and <command>&lt;column&gt;</command> tags specify the layout of the GUI elements. Here you say, that you'd like to place some elements side-by-side (left to right). The <parameter>id</parameter> attribute is not strictly necessary, but we'll use it later on, when adding a wizard interface to our plugin. The first element to place in the row, is:
 	</para>
 	<programlisting>
 					&lt;varselector id="vars"/&gt;
 	</programlisting>
 	<para>
 		Using this simple tag you create a list from which the user can select variables. You have to specify an <parameter>id</parameter> for this element, so &rkward; knows how to find it.
 	</para>
 	<warning>
 		<remark>
 			You may NOT use a dot (.) in the <parameter>id</parameter> string.
 		</remark>
 	</warning>
 	<programlisting>
 					&lt;column&gt;
 	</programlisting>
 	<para>
 		Next, we nest a <command>&lt;column&gt;</command> inside the row. That is the following elements will be placed above each other (top-to-bottom), and all will be to the right of the <command>&lt;varselector&gt;</command>.
 	</para>
 	<programlisting>
 						&lt;varslot types="number" id="x" source="vars" required="true" label="compare"/&gt;
 						&lt;varslot types="number" id="y" source="vars" required="true" label="against" i18n_context="compare against"/&gt;
 	</programlisting>
 	<para>
 		These elements are the counterpart to the <command>&lt;varselector&gt;</command>. They represent <quote>slots</quote> into which the user can put variables. You will note that the <parameter>source</parameter> is set to the same value as the <parameter>id</parameter> of the <command>&lt;varselector&gt;</command>. This means, the <command>&lt;varslot&gt;</command>s will each take their variables from the varselector. The <command>&lt;varslot&gt;</command>s also have to be given an <parameter>id</parameter>. They may have a <parameter>label</parameter>, and they may be set to <parameter>required</parameter>. This means that the <guibutton>Submit</guibutton> button will not be enabled until the <command>&lt;varslot&gt;</command> holds a valid value. Finally the <parameter>type</parameter> attribute is not interpreted yet, but it will be used to take care that only the correct types of variables will be allowed in the <command>&lt;varslot&gt;</command>.
 	</para>
 	<para>
 		In case you are wondering about the <parameter>i18n_context</parameter>-attribute: This is to provide context to help the correct translation of the word "against", used as the
 		<command>&lt;varslot&gt;</command>'s label, but does not affect the functionality of the plugin, directly. More on this in <link linkend="i18n_general">a separate chapter</link>.
 	</para>
 	<programlisting>
 						&lt;radio id="hypothesis" label="using test hypothesis"&gt;
 							&lt;option value="two.sided" label="Two-sided"/&gt;
 							&lt;option value="greater" label="First is greater"/&gt;
 							&lt;option value="less" label="Second is greater"/&gt;
 						&lt;/radio&gt;
 	</programlisting>
 	<para>
 		Here, you define a group of <command>&lt;radio&gt;</command> exclusive buttons. The group has a <parameter>label</parameter> and an <parameter>id</parameter>. Each <command>&lt;option&gt;</command> (button) has a <parameter>label</parameter> and is assigned a <parameter>value</parameter>. This is the value the <command>&lt;radio&gt;</command> element will return when the option is selected.
 	</para>
 	<programlisting>
 					&lt;/column&gt;
 				&lt;/row&gt;
 			&lt;/tab&gt;
 	</programlisting>
 	<para>
 		Each tag has to be closed. We've put all the elements we wanted (the two <command>&lt;varslots&gt;</command> and the <command>&lt;radio&gt;</command>) in the <command>&lt;column&gt;</command>. We put all elements we wanted (the <command>&lt;varselector&gt;</command> and the <command>&lt;column&gt;</command> with those elements) in the <command>&lt;row&gt;</command>. And we've put all the elements we wanted into the first page in the <command>&lt;tabbook&gt;</command>. We're not yet done defining the <command>&lt;tabbook&gt;</command> (more pages to come), and of course there's more to come in the <command>&lt;dialog&gt;</command>, too. But this screenshot is basically what we've done so far:
 	</para>
 	<screenshot>
 	<screeninfo>t-Test plugin</screeninfo>
 		<mediaobject>
 		<imageobject>
 			<imagedata fileref="t_test_plugin_example.png" format="PNG"/>
 		</imageobject>
 		<textobject>
 			<phrase>t-Test plugin</phrase>
 		</textobject>
 		</mediaobject>
 	</screenshot>
 	<para>
 		Note that we have not specified the <guibutton>Submit</guibutton>, <guibutton>Close</guibutton>, &etc; buttons or the code view. Those elements get generated automatically. But of course we still have to define the second page of the <command>&lt;tabbook&gt;</command>:
 	</para>
 	<programlisting>
 			&lt;tab label="Options"&gt;
 				&lt;checkbox id="varequal" label="assume equal variances" value=", var.equal=TRUE"/&gt;
 	</programlisting>
 	<para>
 		By default elements will be placed top-to-bottom like in a <command>&lt;column&gt;</command>. Since that is what we want here, we don't have to explicitly state a <command>&lt;row&gt;</command> or <command>&lt;column&gt;</command> layout. The first element we define is a checkbox. Just like the <command>&lt;radio&gt;</command><command>&lt;option&gt;</command>s, the checkbox has a <parameter>label</parameter> and a <parameter>value</parameter>. The <parameter>value</parameter> is what gets returned, if the check box is checked. Of course the checkbox also needs an <parameter>id</parameter>.
 	</para>
 	<programlisting>
 				&lt;frame label="Confidence Interval" id="frame_conf_int"&gt;
 	</programlisting>
 	<para>
 		Here's yet another layout element: In order to signal that the two elements below  belong together, we draw a <command>&lt;frame&gt;</command> (box). That frame may have a <parameter>label</parameter> (caption). Since the frame is just a passive layout element, it does not need an <parameter>id</parameter>, we still define one here, as we'll refer to it later, when defining an additional wizard interface.
 	</para>
 	<programlisting>
 					&lt;checkbox id="confint" label="print confidence interval" value="1" checked="true"/&gt;
 					&lt;spinbox type="real" id="conflevel" label="confidence level" min="0" max="1" initial="0.95"/&gt;
 				&lt;/frame&gt;
 	</programlisting>
 	<para>
 		Inside the <command>&lt;frame&gt;</command> we place another <command>&lt;checkbox&gt;</command> (using <parameter>checked=</parameter><replaceable>"true"</replaceable>, we signal that check box should be checked by default), and a <command>&lt;spinbox&gt;</command>. The spinbox allows the user to select a value between <replaceable>"min"</replaceable> and <replaceable>"max"</replaceable> with the default/initial value <replaceable>"0.95"</replaceable>. Setting the <parameter>type</parameter> to <replaceable>"real"</replaceable> signals that real numbers are accepted as opposed to <parameter>type=</parameter><replaceable>"integer"</replaceable> which would accept integers only.
 	</para>
 	<note><para>
 		It is also possible, and often preferable, to make the <command>&lt;frame&gt;</command> itself checkable, instead of adding a <command>&lt;checkbox&gt;</command> inside. See the reference for details. This is not done here, for illustrational purposes.
 	</para></note>
 	<programlisting>
 			&lt;/tab&gt;
 		&lt;/tabbook&gt;
 	&lt;/dialog&gt;
 	</programlisting>
 	<para>
 		That's all for the second page of the <command>&lt;tabbook&gt;</command>, all pages in the <command>&lt;tabbook&gt;</command> and all elements in the <command>&lt;dialog&gt;</command>. We're finished defining what the dialog looks like.
 	</para>
 	<programlisting>
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		Finally we close the <command>&lt;document&gt;</command> tag, and that's it. The GUI is defined. You can save the file now. But how does &r; syntax get generated from the GUI-settings? We'll deal with that in the <link linkend="jstemplate">next chapter</link>. First, however, we'll look into adding a wizard interface, and some general considerations.
 	</para>
 </sect1>
 
 <sect1 id="wizard_interface">
 	<title>Adding a wizard interface</title>
 	<para>
 		Actually we don't have to define an additional <command>&lt;wizard&gt;</command> interface, but here's how that would be done. To add a wizard interface, you'll add a <command>&lt;wizard&gt;</command> tag at the same level as the <command>&lt;dialog&gt;</command> tag:
 	</para>
 	<programlisting>
 		&lt;wizard label="Two Variable t-Test"&gt;
 			&lt;page id="firstpage"&gt;
 				&lt;text&gt;As a first step, select the two variables you want to compare against
 					each other. And specify, which one you theorize to be greater. Select two-sided,
 					if your theory does not tell you, which variable is greater.&lt;/text&gt;
 				&lt;copy id="main_settings_row"/&gt;
 			&lt;/page&gt;
 	</programlisting>
 	<para>
 		Some of this is pretty self explanatory: We add a <command>&lt;wizard&gt;</command> tag with a <parameter>label</parameter> for the wizard. Since a wizard can hold several pages that are shown one after another, we next define the first <command>&lt;page&gt;</command>, and put an explanatory <command>&lt;text&gt;</command> note in there. Then we use a <command>&lt;copy&gt;</command> tag. What this does, is really it saves us having to define yet again, what we already wrote for the <command>&lt;dialog&gt;</command>: The copy tag looks for another tag with the same <parameter>id</parameter> earlier in the XML. This happens to be defined in the <command>&lt;dialog&gt;</command> section, and is a <command>&lt;row&gt;</command> in which there are the <command>&lt;varselector&gt;</command>, <command>&lt;varslots&gt;</command> and the <quote>hypothesis</quote> <command>&lt;radio&gt;</command> control. All of this is copied 1:1 and inserted right at the <command>&lt;copy&gt;</command> element.
 	</para>
 	<para>
 		Now to the second page:
 	</para>
 	<programlisting>
 			&lt;page id="secondpage"&gt;
 				&lt;text&gt;Below are some advanced options. It's generally safe not to assume the
 					variables have equal variances. An appropriate correction will be applied then.
 					Choosing "assume equal variances" may increase test-strength, however.&lt;/text&gt;
 				&lt;copy id="varequal"/&gt;
 				&lt;text&gt;Sometimes it's helpful to get an estimate of the confidence interval of
 					the difference in means. Below you can specify whether one should be shown, and
 					which confidence-level should be applied (95% corresponds to a 5% level of
 					significance).&lt;/text&gt;
 				&lt;copy id="frame_conf_int"/&gt;
 			&lt;/page&gt;
 		&lt;/wizard&gt;
 	</programlisting>
 	<para>
 		Much of the same thing here. We add some texts, and in between that <command>&lt;copy&gt;</command> further sections from the dialog interface.
 	</para>
 	<para>
 		You may of course make the wizard interface look very different to the plain dialog, and not use the <command>&lt;copy&gt;</command> tag at all. Be sure, however, to assign corresponding elements the same <parameter>id</parameter> in both interfaces. This is not only used to transfer settings from the dialog interface to the wizard interface and back, when the user switches interfaces (which does not yet happen in the current version of &rkward;), but also simplifies writing your code template (see below).
 	</para>
 </sect1>
 
 <sect1 id="mainxmltips">
 	<title>Some considerations on GUI design</title>
 	<para>
 		This section contains some general considerations on which GUI elements to use where. If this is your first attempt of creating a plugin, feel free to skip over this section, as it isn't relevant to getting a basic GUI working. Come back here, later, to see, whether you can refine your plugin's GUI in some way or another.
 	</para>
 	
 	<sect2 id="radio_vs_checkbox_vs_dropdown">
 		<title>&lt;radio&gt; vs. &lt;checkbox&gt; vs. &lt;dropdown&gt;</title>
 		<para>
 			The three elements <command>&lt;radio&gt;</command>, <command>&lt;checkbox&gt;</command>, <command>&lt;dropdown&gt;</command>, all serve a similar function: To select one out of several options. Obviously, a check box only allows to choose between two options: checked or not checked, so you cannot use it, if there are more than two options to chose from. But when to use which of the elements? Some rules of thumb:
 		</para>
 		<para>
 			If you find yourself creating a <command>&lt;radio&gt;</command> or <command>&lt;dropdown&gt;</command> with only two options, ask yourself, whether the question is essentially a yes / no type of question. E.g. a choice between <quote>adjust results</quote> and <quote>do not adjust results</quote>, or between <quote>remove missing values</quote> and <quote>keep missing values</quote>. In this case a <command>&lt;checkbox&gt;</command> is the best choice: It uses little space, will have the least words of labels, and is easiest to read for the user. There are very few situations where you should chose a <command>&lt;radio&gt;</command> over a <command>&lt;checkbox&gt;</command>, when there are only two options. An example of that might be: <quote>Method of calculation: 'pearson'/'spearman'</quote>. Here, more methods might be thinkable, and they don't really form a pair of opposites.
 		</para>
 		<para>
 			Choosing between a <command>&lt;radio&gt;</command> and a <command>&lt;dropdown&gt;</command> is mostly a question of space. The <command>&lt;dropdown&gt;</command> has the advantage of using little space, even if there are a lot of options to chose from. On the other hand, a <command>&lt;radio&gt;</command> has the advantage of making all possible choices visible to the user at once, without clicking on the dropdown arrow. Generally, if there are six or more options to chose from, a <command>&lt;dropdown&gt;</command> is preferable. If there are five or less options, a <command>&lt;radio&gt;</command> is the better choice.
 		</para>
 	</sect2>
 </sect1>
 </chapter>
 
 <chapter id="jstemplate">
 <title>Generating R code from GUI settings</title>
 <sect1 id="sect_generating_R_code"><title>Using JavaScript in RKWard plugins</title>
 	<para>
 		Now we have a GUI defined, but we still need to generate some &r; code from that. For that, we need another text file, <filename>code.js</filename>, located in the same directory as the <link linkend="mainxml"><filename>description.xml</filename></link>. You may or may not be familiar with JavaScript (or, to be technically precise: ECMA-script). Documentation on JS can be found in abundance, both in printed form, and on the Internet (&eg;: <ulink url="https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide">https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide</ulink>). But for most purposes you will not need to know much about JS at all, as we'll only use some very basic features.
 	</para>
 	<tip>
 		<para>
 			After reading this chapter, have a look at the <link linkend="rkwarddev"><application>rkwarddev</application> package</link> as well. It provides some &r; functions to create JavaScript code commonly used in &rkward;. It can also autodetect variables used in a plugin XML file and create basic JavaScript code from that for you to start with.
 		</para>
 	</tip>
 	<note>
 		<para>
 			Plugin .js files are assumed to be UTF-8 encoded. Be sure to check you editor's encoding, if using any non-ascii characters.
 		</para>
 	</note>
 	<para>
 		For the two variable t-test, the <filename>code.js</filename> file looks as follows (with comments in between):
 	</para>
 	<sect2 id="sect_JS_preprocess"><title>preprocess()</title>
 		<programlisting>
 function preprocess () {
 }
 		</programlisting>
 		<para>
 			The JS file is organized into three separate functions: <function>preprocess()</function>, <function>calculate()</function>, and <function>printout()</function>. This is because not all code is needed at all stages. Currently the preprocess-function is not really used in many places (typically you will omit it altogether).
 		</para>
 	</sect2>
 	<sect2 id="sect_JS_calculate"><title>calculate()</title>
 		<programlisting>
 function calculate () {
 	echo ('res &lt;- t.test (x=' + getString ("x") + ', y=' + getString ("y") + ', hypothesis="' + getString ("hypothesis") + '"' + getString ("varequal"));
 	var conflevel = getString ("conflevel");
 	if (conflevel != "0.95") echo (', conf.level=' + conflevel);
 	echo (')\n');
 }
 		</programlisting>
 		<para>
 			This function generates the actual R syntax to be run from the GUI settings. Let's look at this in detail: The code to be used is generated using <function>echo()</function> statement. Looking at the <function>echo()</function> statement step by step, the first part of it is
 		</para>
 		<screen>
 res &lt;- t.test (
 		</screen>
 		<para>
 			as plain text. Next we need to fill in the value, the user selected as the first variable. We fetch this using <function>getString ("x")</function>, and append it to the string to be <quote>echoed</quote>. This prints out the value of the GUI-element with <parameter>id=</parameter><replaceable>"x"</replaceable>: our first <command>&lt;checkbox&gt;</command>. Next, we append a ', ', and do the same to fetch the value of the element <replaceable>"y"</replaceable> - the second <command>&lt;checkbox&gt;</command>. For the hypothesis (the <command>&lt;radio&gt;</command> group), and the equal variances <command>&lt;checkbox&gt;</command>, the procedure is very similar.
 		</para>
 		<para>
 			Note that instead of concatenating the output snippets with <quote>+</quote>, you can also use several <function>echo()</function> statements. Everything is printed on a single line. To produce a line break in the generated code, insert a <replaceable>"\n"</replaceable> in the echoed string. In theory, you can even produce many lines with a single echo-statement, but please keep it to one line (or less) of generated code per <function>echo()</function>.
 		</para>
 		<note>
 			<para>Besides <function>getString()</function>, there are also functions <function>getBoolean()</function>, which will try to return the value as a logical (suitable for using in an <function>if()</function>-statement), and <function>getList()</function>, which will try to return list-like data in a JS <function>Array()</function>. We will show examples of those, later.</para>
 			<para>When looking at existing plugins, you will also find plenty of plugins using <function>getValue()</function>, instead of <function>getString()</function>, and in fact the two are <emphasis>almost</emphasis> identical. However using <function>getString()</function>, <function>getBoolean()</function> and <function>getList()</function> is the recommended practice since version 0.6.1.
 			</para>
 		</note>
 		<para>
 			It gets a little more tricky for the confidence level. For reasons of aesthetics, we don't want to explicitly specify the confidence level to use, if it corresponds to the default value. Hence, instead of printing the value unconditionally, we first fetch into a variable. Then we check, whether that variable differs from <replaceable>"0.95"</replaceable> and if so print out an additional argument. Finally, we echo a closing bracket and a line break: <replaceable>")\n"</replaceable>. That's all for the calculate function.
 		</para>
 	</sect2>
 	<sect2 id="sect_JS_printout"><title>printout()</title>
 		<programlisting>
 function printout () {
 	echo ('rk.header (' + i18n ("Two Variable t-Test") + ')\n');
 	echo ('rk.print (res)\n');
 }
 		</programlisting>
 		<para>
 			And this was all there is to the printout function in most cases. <function>rk.header()</function> prints a standard headline for the results. Note that in the .js files, you have to
 			mark up all translatable strings by hand, using <command>i18n()</command>, or some alternative commands. More on this in the <link linkend="i18n_js">chapter on internationaliation</link>.
 			You can also add some more information to this, if you like, &eg;:
 		</para>
 		<programlisting>
 function printout () {
 	new Header (i18n ("Two Variable t-Test"))
 	          .addFromUI ("varequal")
 	          .add (i18n ("Confidence level"), getString ("conflevel"))  // Note: written like this for illustration purposes. More automatic:
 	//        .addFromUI ("conflevel")
 	          .print ();
 echo ('rk.print (res)\n');
 }
 		</programlisting>
 		<para>
 			<function>rk.print()</function> utilizes the R2HTML package to provide HTML formatted output. Another helpful function is <function>rk.results()</function>, which can also output different kinds of result tables. If in doubt, however, just use <function>rk.print()</function>, and be done with. The JS class <function>Header</function> is a JS level helper to generate a call to <function>rk.header()</function> (just take a look at the generated &r; code). In some cases you may want to call <function>echo ('rk.header (...)')</function> directly to print a header for your output.
 		</para>
 		<para>
 			Note that internally, the output is just a plain HTML document at this point of time. Therefore you might be tempted to add custom HTML using <function>rk.cat.output()</function>. While this will work, please don't do this. The output format may change (&eg; to ODF) in the future, so it's best not to introduce HTML specific code. Rather keep things simple with <function>rk.header()</function>, <function>rk.print()</function>, <function>rk.results()</function>, and -- if needed -- <function>rk.print.literal()</function>. If those don't seem to satisfy your formatting needs, contact us on the mailing list for help.
 		</para>
 		<para>
 			Congratulations! You created your first plugin. Read on in the next chapters for more advanced concepts.
 		</para>
 	</sect2>
 </sect1>
 
 <sect1 id="jsconventions">
 <title>Conventions, policies, and background</title>
 	<para>
 		There are many ways to write &r; code for a certain task, and there are even more ways to generate this &r; code from JS. How exactly you do it, is left up to you. Still there are a number of considerations that you should follow, and background information you should understand.
 	</para>
 
 	<sect2 id="policylocal">
 	<title>Understanding the <function>local()</function> environment</title>
 		<para>
 			More often than not you will have to create one or more temporary &r; objects in the code generated by your plugin. Normally, you do not want those to be placed in the user's workspace, potentially even overwriting user variables. Hence, all plugin generated code is run in a <function>local()</function> environment (see &r; help page on function <function>local()</function>). This means, all variables you create are temporary and will not be saved permanently.
 		</para>
 		<para>
 			If the user explicitly asks for a variable to be saved, you will need to assign to that object using <function>.GlobalEnv$objectname &lt;- value</function>. In general, do not use the <function>&lt;&lt;-</function> operator. It will not necessarily assign in .GlobalEnv.
 		</para>
 		<para>
 			One important pitfall is using <function>eval()</function>. Here, you need to note that eval will by default use the current environment for evaluation, &ie; the local one. This will work well most of the times, but but not always. Thus, if you need to use <function>eval()</function>, you will probably want to specify the <parameter>envir</parameter> parameter: <function>eval(..., envir=globalenv()</function>).
 		</para>
 	</sect2>
 
 	<sect2 id="policyformatting">
 	<title>Code formatting</title>
 		<para>
 			The most important thing is for your generated &r; code to work, but it should be also easy to read. Therefore, please also keep an eye on formatting. Some considerations:
 		</para>
 		<para>
 			Normal top-level &r; statements should be left aligned.
 		</para>
 		<para>
 			Statements in a lower block should be indented with one tab (see example below).
 		</para>
 		<para>
 			If you do very complex calculations, add a comment here and there, esp. to mark up logical sections. Note that there is a dedicated function <command>comment()</command> for inserting
 			translatable comments in the generated code.
 		</para>
 		<para>
 			For example, generated code might look like this. The same code without indentation or comments would be pretty hard to read, despite its modest complexity:
 		</para>
 		<programlisting>
 # first determine the wobble and rotation
 my.wobble &lt;- wobble (x, y)
 my.rotation &lt;- wobble.rotation (my.wobble, z)
 
 # boggling method needs to be chosen according to rotation
 if (my.rotation &gt; wobble.rotation.limit (x)) {
 	method &lt;- "foo"
 	result &lt;- boggle.foo (my.wobble, my.rotation)
 } else {
 	method &lt;- "bar"
 	result &lt;- boggle.bar (my.wobble, my.rotation)
 }
 		</programlisting>
 	</sect2>
 
 	<sect2 id="policysimplicity">
 	<title>Dealing with complex options</title>
 		<para>
 			Many plugins can do more than one thing. For instance, the <quote>Descriptive Statistics</quote> plugin can compute mean, range, sum, product, median, length, &etc; However, typically the user will only chose to have some of those calculations performed. In this case, please try to keep the generated code as simple as possible. It should only contain portions relevant to the options that are actually selected. To achieve this, here is an example of a common design patterns as you would use it (in JS; here, "domean", "domedian", and "dosd" would be &lt;checkbox&gt; elements):
 		</para>
 		<programlisting>
 function calculate () {
 	echo ('x &lt;- &lt;' + getString ("x") + ')\n');
 	echo ('results &lt;- list ()\n');
 
 	if (getBoolean ("domean.state")) echo ("results$" + i18n ("Mean value") + " &lt;- mean (x)\n");
 	if (getBoolean ("domedian.state")) echo ("results$" + i18n ("Median") + " &lt;- median (x)\n");
 	if (getBoolean ("dosd.state")) echo ("results$" + i18n ("Standard deviation") + " &lt;- sd (x)\n");
 	//...
 }
 		</programlisting>
 	</sect2>
 </sect1>
 
 <sect1 id="jstips">
 <title>Tips and tricks</title>
 	<para>
 		Here are a few assorted tricks which may make writing plugins less tedious:
 	</para>
 	<para>
 		If you need the value of a GUI setting at several places in you plugin's code, consider assigning it to a variable in JS, and using that instead of fetching it again and again with <function>getString()/getBoolean()/getList()</function>. This is faster, more readable, and less typing all at the same time:
 	</para>
 	<programlisting>
 function calculate () {
 	var narm = "";	// na.rm=FALSE is the default in all functions below
 	if (getBoolean ("remove_nas")) {
 		$narm = ", na.rm=TRUE";
 	}
 	// ...
 	echo ("results$foo &lt;- foo (x" + narm + ")\n");
 	echo ("results$bar &lt;- bar (x" + narm + ")\n");
 	echo ("results$foobar &lt;- foobar (x" + narm "\n");
 	// ...
 }
 	</programlisting>
 	<para>
 		The simple helper function <function>makeOption()</function> can make it easier to omit parameters that are at their default value, in many cases:
 	</para>
 	<programlisting>
 function calculate () {
 	var options
 	//...
 	// This will do nothing, if VALUE is 0.95 (the default). Otherwise it will append ', conf.int=VALUE' to options.
 	options += makeOption ("conf.int", getString ("confint"), "0.95");
 	//...
 }
 	</programlisting>
 </sect1>
 </chapter>
 
 <chapter id="pluginhelp">
 	<title>Writing a help page</title>
 	<para>
 		When your plugin basically works, the time has come to provide a help page. While typically you will not want to explain all the underlying concepts in depth, you may want to add some more explanation for some of the options, and link to related plugins and &r; functions.
 	</para>
 	<tip>
 		<para>
 			After reading this chapter, have a look at the <link linkend="rkwarddev"><application>rkwarddev</application> package</link> as well. It provides some &r; functions to create most of &rkward;'s XML tags for you. It's also capable of creating basic help file skeletons from existing plugin XML files for you to start with.
 		</para>
 	</tip>
 	<para>
 		You may recall putting this inside your plugin XML (if you haven't put this in, do so now):
 	</para>
 	<programlisting>
 &lt;document&gt;
 	[...]
 	&lt;help file="filename.rkh" /&gt;
 	[...]
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		Where, obviously, you'd replace <filename>filename</filename> with a more appropriate name. Now it's time to create this <literal role="extension">.rkh</literal> file. Here is a self-descriptive example:
 	</para>
 	<programlisting>
 &lt;!DOCTYPE rkhelp&gt;
 &lt;document&gt;
 	&lt;summary&gt;
 In this section, you'll put some short, very basic information about what the plugin does.
 This section will always show up on the very top of the help page.
 	&lt;/summary&gt;
 
 	&lt;usage&gt;
 The usage section may contain a little more practical information. It does not explain all
 the settings in detail (that's done in the "settings" section), however.
 
 To start a new paragraph, insert an empty line, as shown above.
 This line, in contrast, will be in the same paragraph.
 
 In all sections you can insert some simple HTML code, such as &lt;b&gt;bold&lt;/b&gt; or
 &lt;i&gt;italic&lt;/i&gt; text. Please keep formatting to the minimum needed, however.
 
 The usage section is always the second section shown in a help page.
 	&lt;/usage&gt;
 
 	&lt;section id="sectionid" title="Generic section" short_title="Generic"&gt;
 If you need to, you can add additional sections between the usage and settings sections.
 However, usually, you will not need this while documenting plugins. The "id"-attribute
 provides an anchor point to jump to this section from the navigation menu. The "short_title"
 attribute provides a short title to use in the navigation bar. This is optional, by default
 the main "title" will be used both as a heading to the section, and as the link name in the
 navigation bar.
 
 In any section you may want to insert links to further information. You do this by adding
 
 &lt;link href="URL"&gt;link name&lt;/link&gt;
 
 Where URL could be an external link such as http://rkward.kde.org .
 Several special URLs are supported in the help pages:
 
 &lt;link href="rkward://page/path/page_id"/&gt;
 
 This links to a top level rkward help page (not for a plugin).
 
 &lt;link href="rkward://component/[namespace/]component_id"/&gt;
 
 This links to the help page of another plugin. The [namespace/] part may be omitted
 (in this case, rkward is assumed as the standard namespace, &eg;:
 &lt;link href="rkward://component/import_spss"/&gt; or
 &lt;link href="rkward://component/rkward/import_spss"/&gt; are equivalent).
 The component_id is the same that you specified in the <link linkend="pluginmap">&pluginmap;</link>.
 
 &lt;link href="rkward://rhelp/rfunction"/&gt;
 
 Links to the R help page on "rfunction".
 
 Note that the link names will be generated automatically for these types of links.
 	&lt;/section&gt;
 
 	&lt;settings&gt;
 		&lt;caption id="id_of_tab_or_frame"/&gt;
 		&lt;setting id="id_of_element"&gt;
 Description of the GUI element identified by the given id
 		&lt;/setting&gt;
 		&lt;setting id="id_of_elementb" title="description"&gt;
 Usually the title of the GUI element will be extracted from the
 <link linkend="mainxml">XML definition of the plugin</link>, automatically. However,
 for some GUI elements, this description may not be enough to identify them, reliably.
 In this case, you can add an explicit title using the "title" attribute.
 		&lt;/setting&gt;
 		&lt;setting id="id_of_elementc"&gt;
 Description of the GUI element identified by "id_of_elementc"
 		&lt;/setting&gt;
 		[...]
 	&lt;/settings&gt;
 
 	&lt;related&gt;
 The related section typically just contains some links, such as:
 
 &lt;ul&gt;
 	&lt;li&gt;&lt;link href="rkward://rhelp/mean"/&gt;&lt;/li&gt;
 	&lt;li&gt;&lt;link href="rkward://rhelp/median"/&gt;&lt;/li&gt;
 	&lt;li&gt;&lt;link href="rkward://component/related_component"/&gt;&lt;/li&gt;
 &lt;/ul&gt;
 	&lt;/related&gt;
 
 	&lt;technical&gt;
 The technical section (optional, always last) may contain some technical details of the plugin
 implementation, which are of interest only to RKWard developers. This is particularly relevant
 for plugins that are designed to be embedded in many other plugins, and could detail, which
 options are available to customize the embedded plugin, and which code sections contain which
 R code.
 	&lt;/technical&gt;
 &lt;/document&gt;
 	</programlisting>
 </chapter>
 
 
 <chapter id="logic">
 <title>Logic interactions between GUI elements</title>
 <sect1 id="sect_GUI_logic"><title>GUI logic</title>
 	<para>
 		All the basic concepts of creating a plugin for &rkward; have been described in the previous chapters. Those basic concepts should be sufficient for many -- if not most -- cases. However, sometimes you want more control over how your plugin's GUI behaves.
 	</para>
 	<para>
 		For instance, suppose you want to extend the t-test example used in this documentation to allow both: comparing a variable against another variable (as shown), and comparing a variable against a constant value. Now, one way of doing this would be to add a radio-control that switches between the two modes, and adding a spinbox to enter the constant value to compare against. Consider this simplified example:
 	</para>
 	<programlisting>
 &lt;!DOCTYPE rkplugin&gt;
 &lt;document&gt;
 	&lt;code file="code.js"/&gt;
 
 	&lt;dialog label="T-Test"&gt;
 		&lt;row&gt;
 			&lt;varselector id="vars"/&gt;
 			&lt;column&gt;
 				&lt;varslot id="x" types="number" source="vars" required="true" label="compare"/&gt;
 				&lt;radio id="mode" label="Compare against"&gt;
 					&lt;option value="variable" checked="true" label="another variable (select below)"/&gt;
 					&lt;option value="constant" label="a constant value (set below)"/&gt;
 				&lt;/radio&gt;
 				&lt;varslot id="y" types="number" source="vars" required="true" label="variable" i18n_context="Noun; a variable"/&gt;
 				&lt;spinbox id="constant" initial="0" label="constant" i18n_context="Noun; a constant"/&gt;
 			&lt;/column&gt;
 		&lt;/row&gt;
 	&lt;/dialog&gt;
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		So far so good, but there are a number of problems with this GUI. First, both the varslot and the spinbox are always shown, whereas only one of the two is really used. Worse, the varslot always requires a valid selection, even if you compare against a constant. Obviously, if we create a multi-purpose GUI like this, we want more flexibility. Enter: the <command>&lt;logic&gt;</command> section (inserted at the same level as <command>&lt;code&gt;</command>, <command>&lt;dialog&gt;</command>, or <command>&lt;wizard&gt;</command>).
 	</para>
 	<programlisting>
 	[...]
 	&lt;code file="code.js"/&gt;
 
 	&lt;logic&gt;
 		&lt;convert id="varmode" mode="equals" sources="mode.string" standard="variable" /&gt;
 
 		&lt;connect client="y.visible" governor="varmode" /&gt;
 		&lt;connect client="constant.visible" governor="varmode.not" /&gt;
 	&lt;/logic&gt;
 
 	&lt;dialog label="T-Test"&gt;
 	[...]
 	</programlisting>
 	<para>
 		The first line inside the logic section is a <command>&lt;convert&gt;</command> tag. Basically, this provides a new boolean (on or off, true or false) property, which can be used later on. This property (<replaceable>"varmode"</replaceable>) is true, whenever the upper radio button is selected and false whenever the lower radio button is selected. How is this done?
 	</para>
 	<para>
 		First, under <parameter>sources</parameter>, the source properties to work on are listed (in this case only one each; you could list several as <parameter>sources=</parameter><replaceable>"mode.string;somethingelse"</replaceable>, then <replaceable>"varmode"</replaceable> would only be true, if both <replaceable>"mode.string"</replaceable> and <replaceable>"somethingelse"</replaceable> are equal to the string <replaceable>"variable"</replaceable>). Note that in this case we don't just write <replaceable>"mode"</replaceable> (as we would in <function>getString("mode")</function>, but <replaceable>"mode.string"</replaceable>. This is actually the internal way a radio control works: It has a property <quote>string</quote>, which holds its string value. <function>getString("mode")</function> is just a shorthand, and equivalent to <function>getString("mode.string")</function>. See the reference for all properties of the different GUI elements.
 	</para>
 	<para>
 		Second, we set the mode of conversion to <parameter>mode=</parameter><replaceable>"equals"</replaceable>. This means, we want to check, whether the source(s) is (are) equal to a certain value. Finally standard is the value to compare against, so with <parameter>standard=</parameter><replaceable>"variable"</replaceable>, we check whether the property <replaceable>"mode.string"</replaceable> is equal to the string <replaceable>"variable"</replaceable> (the value of the upper radio option). If it is equal, then the property varmode is true, else it is false.
 	</para>
 	<para>
 		Now to the real stuff: We <command>&lt;connect&gt;</command> the <replaceable>"varmode"</replaceable> property to y.visible, which controls whether the varslot <replaceable>"y"</replaceable> is shown or not. Note that any element which is made invisible is implicitly non-required. Thus, if the upper radio-option is selected, the varslot <replaceable>"y"</replaceable> is required, and visible. Else it is not required and hidden.
 	</para>
 	<para>
 		For the spinbox, we want the exact reverse. Fortunately, we do not need another <command>&lt;convert&gt;</command> for this: Boolean
 		properties can be negated very easily by appending the modifier <replaceable>"not"</replaceable>, so we <command>&lt;connect&gt;</command> <replaceable>"varmode.not"</replaceable> to the spinbox's visibility property. In effect, either
 		the varslot is shown and required, <emphasis>or</emphasis> the spinbox is shown and required - depending on which option is selected in the radio control. The GUI is changing itself according to the radio option. Try the example, if you like.
 	</para>
 	<para>
 		For a complete list of properties, refer to the <link linkend="reference">reference</link>. One more property, however, is special in that all GUI elements have it: <quote>enabled</quote>. This is slightly less drastic that <quote>visible</quote>. It does not show/hide the GUI element, but only enables/disables it. Disabled elements are typically shown grayed out, and do not react to user input.
 	</para>
 	<note>
 		<para>Besides <command>&lt;convert&gt;</command> and <command>&lt;connect&gt;</command>, there are several further elements for use in the <command>&lt;logic&gt;</command> section. E.g. conditional constructs can also be implemented using the <command>&lt;switch&gt;</command>-element. Refer to the <link linkend="logicelements">reference on logic elements</link> for details.</para>
 	</note>
 </sect1>
 <sect1 id="logic_scripted">
 <title>Scripted GUI logic</title>
 	<para>
 		While connecting properties as described above is often enough, sometimes it is more flexible or more convenient to use JS to script the GUI logic. In this way, the above example could be re-written as:
 	</para>
 	<programlisting>
 	[...]
 	&lt;code file="code.js"/&gt;
 '
 	&lt;logic&gt;
 		&lt;script&gt;&lt;![CDATA[
 			// ECMAScript code in this block
 			// the top-level statement is only called once
 			gui.addChangeCommand ("mode.string", "modeChanged ()");
 
 			// this function is called whenever the "mode" was changed
 			modeChanged = function () {
 				var varmode = (gui.getString ("mode.string") == "variable");
 				gui.setValue ("y.enabled", varmode);
 				gui.setValue ("constant.enabled", !varmode);
 			}
 		]]&gt;&lt;/script&gt;
 	&lt;/logic&gt;
 
 	&lt;dialog label="T-Test"&gt;
 	[...]
 	</programlisting>
 	<para>
 		The first line of code tells &rkward; to call the function <function>modeChanged()</function> whenever the value of the <parameter>id=</parameter><replaceable>"mode"</replaceable> radio box changes. Inside this function, we define a helper-variable <replaceable>"varmode"</replaceable> which is true when the mode is <replaceable>"variable"</replaceable>, false is it is <replaceable>"constant"</replaceable>. Then we use <function>gui.setValue()</function> to set the and <quote>enabled</quote> properties of <replaceable>"y"</replaceable> and <replaceable>"constant"</replaceable>, in just the same way as we did using <command>&lt;connect&gt;</command> statements, before.
 	</para>
 	<para>
 		The scripted approach to GUI logic becomes particularly useful when you want to change the available option according to the type of object that the user has selected. See <link linkend="guilogic_functions">the reference</link> for available functions.
 	</para>
 	<para>
 		Note that the scripted approach to GUI logic can be mixed with <command>&lt;connect&gt;</command> and <command>&lt;convert&gt;</command>-statements if you like. Also note that the <command>&lt;script&gt;</command> tag allows to specify a script file name in addition to or as an alternative to inlining the script code. Typically, inlining the script code as shown above is most convenient, however.
 	</para>
 </sect1>
 </chapter>
 
 <chapter id="embedding">
 <title>Embedding Plugins into Plugins</title>
 <sect1 id="sect_embedding"><title>Use cases for embedding</title>
 	<para>
 		When writing plugins, you will often find that you're creating a number of plugins that only differ in some respects, but have a lot more in common. For instance, for plotting, there are a number of generic &r; options that can be used with mostly all types of plots. Should you create a GUI and JS-template for those over and over again?
 	</para>
 	<para>
 		Obviously that would be quite a hassle. Fortunately, you don't have to do that. Rather you create the common functionality once, and later you can embed it into several plugins. In fact it is possible to embed any plugin into any other plugin, even if the original author of the embedded plugin never thought, somebody would want to embed their plugin into another one.
 	</para>
 </sect1>
 <sect1 id="embedding_dialog">
 <title>Embedding inside a dialog</title>
 	<para>
 		Ok, enough said. How does it work? Simple: Just use the <command>&lt;embed&gt;</command> tag. Here's a stripped down example:
 	</para>
 	<programlisting>
 &lt;dialog&gt;
 	&lt;tabbook&gt;
 		&lt;tab [...]&gt;
 			[...]
 		&lt;/tab&gt;
 		&lt;tab label="Plot Options" i18n_context="Options concerning the plot"&gt;
 			&lt;embed id="plotoptions" component="rkward::plot_options"/&gt;
 		&lt;/tab&gt;
 		&lt;tab [...]&gt;
 			[...]
 		&lt;/tab&gt;
 	&lt;/tabbook&gt;
 &lt;/dialog&gt;
 	</programlisting>
 	<para>
 		What happens here, is that the entire GUI or the plot options plugin (except of course for the standard elements like <guibutton>Submit</guibutton> button, &etc;) is embedded right into your plugin (try it!).
 	</para>
 	<para>
 		As you can see the syntax of the <command>&lt;embed&gt;</command>-tag is fairly simple. It takes an <parameter>id</parameter> as most elements. The parameter component specifies which plugin to embed, as defined in the &pluginmap; file (<replaceable>"rkward::plot_options"</replaceable> is the result of concatenating the namespace <quote>rkward</quote>, a separator <quote>::</quote>, and the name of the component <quote>plot_options</quote>).
 	</para>
 </sect1>
 <sect1 id="embedding_code">
 <title>Code generation when embedding</title>
 	<para>
 		So far so good, but what about the generated code? How are the code for the embedding and embedded plugin merged? In the embedding plugin's JS code, simply write something like this:
 	</para>
 	<programlisting>
 function printout () {
 	// ...
 	echo ("myplotfunction ([...]" + getString ("plotoptions.code.printout"); + ")\n");
 	// ...
 }
 	</programlisting>
 	<para>
 		So essentially, we're fetching the code generated by the embedded plugin just like we're fetching any other GUI setting. Here the string <replaceable>"plotoptions.code.printout"</replaceable> can be deparsed to: <quote>The printout section of the generated code of the element with the <parameter>id</parameter> plotoptions</quote> (plotoptions is the ID we gave for the <command>&lt;embed&gt;</command> tag above). And yes, if you want advanced control, you can even fetch the values of individual GUI elements inside the embedded plugin (but not the other way around, as the embedded plugin does not know anything about its surroundings).
 	</para>
 </sect1>
 <sect1 id="embedding_wizard">
 <title>Embedding inside a wizard</title>
 	<para>
 		If your plugin provides a wizard GUI, embedding works basically in the same way. You'll generally use:
 	</para>
 	<programlisting>
 	&lt;wizard [...]&gt;
 		[...]
 		&lt;page id="page12"&gt;
 			[...]
 		&lt;/page&gt;
 		&lt;embed id="plotoptions" component="rkward::plot_options"/&gt;
 		&lt;page id="page13"&gt;
 			[...]
 		&lt;/page&gt;
 		[...]
 	&lt;/wizard&gt;
 	</programlisting>
 	<para>
 		If the embedded plugin provides a wizard interface, its pages will be inserted right between <replaceable>"page12"</replaceable> and <replaceable>"page13"</replaceable> of your plugin. If the embedded plugin provides a dialog interface only, a single new page will be added between your pages <replaceable>"page12"</replaceable> and <replaceable>"page13"</replaceable>. The user will never notice.
 	</para>
 </sect1>
 <sect1 id="embedding_as_button">
 <title>Less embedded embedding: Further Options button</title>
 	<para>
 		While embedding is cool, you should be careful not to overdo it. Too many functions inside a GUI just make it hard to find the relevant options. Of course, sometimes you may want to embed a great deal of options (like all the options to <function>plot()</function>), but as those are really optional, you don't want them prominently in your GUI.
 	</para>
 	<para>
 		An alternative is to embed those options <quote>as a button</quote>:
 	</para>
 	<programlisting>
 &lt;dialog&gt;
 	&lt;tabbook&gt;
 		[...]
 		&lt;tab label="Options"&gt;
 			[...]
 			&lt;embed id="plotoptions" component="rkward::plot_options" as_button="true" label="Specify plotting options"/&gt;
 		&lt;/tab&gt;
 		[...]
 	&lt;/tabbook&gt;
 &lt;/dialog&gt;
 </programlisting>
 	<para>
 		In this case, a single push button will be added to your plugin, labelled <guibutton>Specify plotting options</guibutton>. When you press that button, a separate dialog will come up, with all the options of the embedded plugin. Even while this embedded GUI is not visible most of the time, you can fetch its settings just as described <link linkend="embedding_code">above</link>.
 	</para>
 	<para>
 		<caution>
 			<remark>
 				Probably the <quote>button</quote> approach should only ever be used for plugins that can never be invalid (for missing/bad settings). Otherwise the user would not be able to submit the code, but might have a hard time finding out, the reason for that is hidden behind some button.
 			</remark>
 		</caution>
 	</para>
 </sect1>
 <sect1 id="embedding_incomplete">
 <title>Embedding/defining incomplete plugins</title>
 	<para>
 		Some plugins -- and as a matter of fact, the plot_options used as an example above, is one of them -- are not complete by themselves. They simply do not have the GUI elements to select some important values. They are meant to be used only embedded into other plugins.
 	</para>
 	<para>
 		In how far is the plot_options plugin incomplete? Well, for some option settings, it needs to know the name of the objects/expressions for the x and y axes (actually it will do fine if it only has either, but it needs at least one to function properly). However, it does not have a mechansim of selecting those objects, or entering them any other way. So how does it know about them?
 	</para>
 	<para>
 		In the logic section of the plot_options plugin there are two additional lines, not covered, yet:
 	</para>
 	<programlisting>
 	&lt;logic&gt;
 		&lt;external id="xvar" /&gt;
 		&lt;external id="yvar" /&gt;
 
 		[...]
 	&lt;/logic&gt;
 	</programlisting>
 	<para>
 		This defines two additional properties in the plot_options plugin, whose sole purpose is to be connected to some (yet unknown) properties of the embedding plugin. In the plot_options plugin those two properties are simply used like any other, and for instance there are calls to <function>getString("xvar")</function> in the plot_options JS template.
 	</para>
 	<para>
 		Now, for the incomplete plugin there is no way of knowing, where it will be embedded, and what the relevant settings in the embedding plugin will be called. So we need to add two additional lines in the embedding plugin's logic section as well:
 	</para>
 	<programlisting>
 	&lt;logic&gt;
 		[...]
 
 		&lt;connect client="plotoptions.xvar" governor="xvarslot.available" /&gt;
 		&lt;connect client="plotoptions.yvar" governor="yvarslot.available" /&gt;
 	&lt;/logic&gt;
 	</programlisting>
 	<para>
 		This is nothing new in principle, we've covered <command>&lt;connect&gt;</command> statements in the <link linkend="logic">chapter of GUI logic</link>. You simply connect the values in two varlots (called <replaceable>"xvarslot"</replaceable> and <replaceable>"yvarslot"</replaceable> in this example) to the receiving <quote>external</quote> properties of the embedded plugin. That's it. Everything else is taken care of automatically.
 	</para>
 </sect1>
 </chapter>
 
 <chapter id="plugin_series">
 <title>Dealing with many similar plugins</title>
 <sect1 id="sect_similar_plugins"><title>Overview on different approaches</title>
 	<para>
 		Sometimes, you may wish to develop plugins for a series of similar functions. As an example, consider the distribution plots. These generate fairly similar code, and of course it's desirable to make the graphical interfaces look similar to each other. Finally large sections of the help files can be identical. Only a few parameters are different for each plugin.
 	</para>
 	<para>
 		The naive approach to this is to develop one plugin, then basically copy and paste the entire contents of the <literal role="extension">.js</literal>, <literal role="extension">.xml</literal>, and <literal role="extension">.rkh</literal> files, then changing the few portions that are different. However, what if sometime later you find a spelling mistake that has been copied and pasted to all plugins? What if you want to add support for a new feature? You'd have to visit all plugins again, and change each single one. A tiresome and tedious process.
 	</para>
 	<para>
 		A second approach would be to use <link linkend="embedding">embedding</link>. However, in some cases this does not lend itself well to the problem at hand, mostly because the <quote>chunks</quote> you can embed are sometimes too large to be useful, and it places some constraints on the layout. For these cases, the concepts <link linkend="include_js">including <literal role="extension">.js</literal> files</link> <link linkend="include_xml">including <literal role="extension">.xml</literal> files</link> and <link linkend="snippets">snippets</link> can be very useful (but see the <link linkend="include_snippets_vs_embedding">thoughts on when it is preferable to use embedding</link>).
 	</para>
 	<para>
 		One word of caution, before you begin reading, though: These concepts can help making it simpler to deal with many similar plugins, and can improve maintainability and readability of those plugins. However, overdoing it can easily lead to the reverse effect. Use with some caution.
 	</para>
 </sect1>
 <sect1 id="include_js">
 <title>Using the JS include statement</title>
 	<para>
 		You can easily include one script file into another in &rkward; plugins. The value of this becomes immediately obvious, if some sections of your JS code are similar across plugins. You can simply define those sections in a separate <literal role="extension">.js</literal> file, and include this in all the plugin <literal role="extension">.js</literal> files. For example, as in:
 	</para>
 	<programlisting>
 // this is a file called "common_functions.js"
 
 function doCommonStuff () {
 	// perhaps fetch some options, etc.
 	// ...
 	comment ("This is R code you want in several different plugins\n");
 	// ...
 }
 	</programlisting>
 	<programlisting>
 // this is one of your regular plugin <literal role="extension">.js</literal> files
 
 // include the common functions
 include ("common_functions.js");
 
 function calculate () {
 	// do something
 	// ...
 
 	// insert the common code
 	doCommonStuff ();
 }
 	</programlisting>
 	<para>
 		Note that sometimes it's even more useful to reverse this, and define the <quote>skeleton</quote> of <function>preprocess()</function>, <function>calculate()</function>, and <function>printout()</function> functions is a common file, and make these call back for those part which are different across plugins. E.g.:
 	</para>
 	<programlisting>
 // this is a file called "common_functions.js"
 
 function calculate () {
 	// do some things which are the same in all plugins
 	// ...
 
 	// add in something that is different across plugins
 	getSpecifics ();
 
 	// ...
 }
 	</programlisting>
 	<programlisting>
 // this is one of your regular plugin <literal role="extension">.js</literal> files
 
 // include the common functions
 include ("common_functions.js");
 
 // note: no calculate() function is defined in here.
 // it in the common_functions.js, instead.
 
 function getSpecifics () {
 	// print some R code
 }
 	</programlisting>
 	<para>
 		One issue you should be aware of when using this technique is variable scoping. See the JS manual on variable scopes.
 	</para>
 	<para>
 		This technique is heavily used in the distribution plot and distribution CLT plot plugins, so you may want to look there for examples.
 	</para>
 </sect1>
 
 <sect1 id="include_xml">
 <title>Including <literal role="extension">.xml</literal> files</title>
 	<para>
 		Basically the same feature of including files is also available for use in the <literal role="extension">.xml</literal>, &pluginmap; and <literal role="extension">.rkh</literal> files. At any place in these files you can place an <command>&lt;include&gt;</command> tag as shown below. The effect is that the entire contents of that XML file (to be precise: everything within the <command>&lt;document&gt;</command> tag of that file) is included verbatim at this point in the file. Note that you can only include another XML file.
 	</para>
 	<programlisting>
 &lt;document&gt;
 	[...]
 	&lt;include file="another_xml_file.xml"/&gt;
 	[...]
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		The attribute <parameter>file</parameter> is the filename relative to the directory the current file is located in.
 	</para>
 </sect1>
 
 <sect1 id="snippets">
 <title>Using &lt;snippets&gt;</title>
 	<para>
 		While including files as shown in the <link linkend="include_xml">previous section</link> is fairly powerful, it become most useful when used in combination with <command>&lt;snippets&gt;</command>. Snippets are really smaller sections which you can insert at another point in the file. An example illustrates this best:
 	</para>
 	<programlisting>
 &lt;document&gt;
 	&lt;snippets&gt;
 		&lt;snippet id="note"&gt;
 			&lt;frame&gt;
 				&lt;text&gt;
 		This will be inserted at two places in the GUI
 				&lt;/text&gt;
 			&lt;/frame&gt;
 		&lt;/snippet&gt;
 	&lt;/snippets&gt;
 	&lt;dialog label="test"&gt;
 		&lt;column&gt;
 			&lt;insert snippet="note"/&gt;
 			[...]
 			&lt;insert snippet="note"/&gt;
 		&lt;/column&gt;
 	&lt;/dialog&gt;
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		Hence, you define the snippet at one place at the top of the XML file, and then you <command>&lt;insert&gt;</command> it at any place(s) you wish.
 	</para>
 	<para>
 		While this example is not too useful in itself, think about combining this with an <command>&lt;include&gt;</command>d <literal role="extension">.xml</literal> file. Note that you can also place snippets for the <literal role="extension">.rkh</literal> file in the same file. You'd simply <command>&lt;include&gt;</command> the file there as well, and <command>&lt;insert&gt;</command> the relevant snippet:
 	</para>
 	<programlisting>
 &lt;!-- This is a file called "common_snippets.xml" --&gt;
 &lt;document&gt;
 	&lt;snippet id="common_options"&gt;
 		&lt;spinbox id="something" [...]/&gt;
 		[...]
 	&lt;/snippet&gt;
 	&lt;snippet id="common_note"&gt;
 		&lt;text&gt;An important note for this type of plugin&lt;/text&gt;
 	&lt;/snippet&gt;
 
 	&lt;snippet id="common_help"&gt;
 		&lt;setting id="something"&gt;This does something&lt;/setting&gt;
 		[...]
 	&lt;/snippet&gt;
 &lt;/document&gt;
 	</programlisting>
 	<programlisting>
 &lt;!-- This is the .xml file of the plugin --&gt;
 &lt;document&gt;
 	&lt;snippets&gt;
 		&lt;!-- Import the common snippets --&gt;
 		&lt;include file="common_snippets.xml"/&gt;
 	&lt;/snippets&gt;
 
 	&lt;dialog label="test2"&gt;
 		&lt;insert snippet="common_note"/&gt;
 		&lt;spinbox id="something_plugin_specific" [...] /&gt;
 		&lt;insert snippet="common_options"/&gt;
 	&lt;/dialog&gt;
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		Similar to <link linkend="include_js">inclusion in JS</link>, the reverse approach is often even more useful:
 	</para>
 	<programlisting>
 &lt;!-- This is a file called "common_layout.xml" --&gt;
 &lt;document&gt;
 	&lt;column&gt;
 		&lt;insert snippet="note"&gt;
 		[...]
 		&lt;insert snippet="plugin_parameters"&gt;
 	&lt;/column&gt;
 	[...]
 &lt;/document&gt;
 	</programlisting>
 	<programlisting>
 &lt;!-- This is the .xml file of the plugin --&gt;
 &lt;document&gt;
 	&lt;snippets&gt;
 		&lt;snippet id="note"&gt;
 			&lt;text&gt;The note used for this specific plugin&lt;/text&gt;
 		&lt;/snippet&gt;
 
 		&lt;snippet id="plugin_parameters"&gt;
 			&lt;frame label="Parameters specific to this plugin"&gt;
 				[...]
 			&lt;/frame&gt;
 		&lt;/snippet&gt;
 	&lt;/snippets&gt;
 
 	&lt;dialog label="test3"&gt;
 		&lt;include file="common_layout.xml"/&gt;
 	&lt;/dialog&gt;
 &lt;/document&gt;
 	</programlisting>
 	<para>
 		Finally, it is also possible to <command>&lt;insert&gt;</command> snippets into other snippets, provided that: a) there is only one level of nesting, and b) the <command>&lt;snippets&gt;</command> section is placed at the top of the file (before a nested snippet is inserted); this is because <command>&lt;insert&gt;</command> statements are resolved from top to bottom.
 	</para>
 </sect1>
 
 <sect1 id="include_snippets_vs_embedding">
 <title>&lt;include&gt; and &lt;snippets&gt; vs. &lt;embed&gt;</title>
 	<para>
 		At first glance, <command>&lt;include&gt;</command> and <command>&lt;snippets&gt;</command> provides functionality rather similar to <link linkend="embedding">embedding</link>: It allows to reuse some portions of code across plugins. So what's the difference between these approaches, and when should you use which?
 	</para>
 	<para>
 		The key difference between these concepts is that embeddable plugins are a more tight bundle. They combine a complete GUI, code to generate &r; code from this, and a help page. In contrast, include and insert allow much more fine grained control, but at the price of less modularity.
 	</para>
 	<para>
 		That is, a plugin embedding another plugin will typically not need to know much about the internal details of the embedded plugin. A prime example is the plot_options plugin. Plugins wishing to embed this do not necessarily need to know about all the options provided, or how they are provided. This is a good thing, as otherwise a change in the plot_options plugin might make it necessary to adjust all plugins embedding this (a lot). In contrast, include and insert really exposes all the internal details, and plugins using this will -- for example -- need to know the exact ids and perhaps even the type of the elements used.
 	</para>
 	<para>
 		Hence the rule of thumb is this: include and insert are great if the relevant options are only needed for a clearly limited group of plugins. Embedded plugins are better, if the group of plugins it may be useful to is not clearly defined, and if the functionality can easily be modularized. Another rule of thumb: If you can put the common portions into a single <quote>chunk</quote>, then do so, and use embedding. If you need lots of small snippets to define the common portions -- well, use <command>&lt;snippets&gt;</command>. A final way to look at it: If all plugins provide <emphasis>highly</emphasis> similar functionality, includes and inserts are probably a good idea. If they merely share one or two common <quote>modules</quote>, embedding is likely better.
 	</para>
 </sect1>
 </chapter>
 
 <chapter id="specialized_plugins">
 <title>Concepts for use in specialized plugins</title>
 <para>
 This chapter contains information on some topics that are useful only to certain classes of plugins.
 </para>
 
 <sect1 id="specialized_plugins_plots">
 	<title>Plugins than produce a plot</title>
 	<para>
 		Creating a plot from a plugin is easy to do. However, there are a few sublte gotchas to avoid, and also some great generic functionality that you should be aware of. This section shows you the basic concepts, and concludes with a canonical example that you should follow whenever creating plot plugins.
 	</para>
 	<sect2 id="rk_graph_on">
 		<title>Drawing a plot to the output window</title>
 		<para>
 			In order to draw a plot to the output window, use <function>rk.graph.on()</function> directly before creating the plot, and
 			<function>rk.graph.off()</function>, directly afterwards. This is similar to &eg; calling <function>postscript()</function> and 
 			<function>dev.off()</function> in a regular R session.
 		</para>
 		<para>
 			Importantly, however, you must <emphasis>always</emphasis> call <function>rk.graph.off()</function> after calling <function>rk.graph.on()</function>. Otherwise the output file will be left in a broken state. To ensure <function>rk.graph.off()</function> really gets called, you should wrap <emphasis>all</emphasis> R commands between the two calls in
 			<function>try()</function> statement. Never heard of that? Don't worry, it's easy. All you need to do is follow the pattern shown in
 			<link linkend="plot_plugin_example">example</link>, below.
 		</para>
 	</sect2>
 	<sect2 id="preview_plots">
 		<title>Adding preview functionality</title>
 		<note><para>This section discusses adding preview functionality to plugins producing plots. There are separate sections on <link linkend="preview_output">previews of (HTML) output</link>, <link linkend="preview_data">previews of (imported) data</link>, and <link linkend="preview_custom">custom previews</link>. However, it is recommended that you read this section first, as the approach is similar in each case.</para></note>
 		<para>
 			A very useful feature for all plugins generating a plot/graph is to provide an automatically updating preview. To do so, you will need two things: Adding a <command>&lt;preview&gt;</command> check box to your <link linkend="mainxml">GUI definition</link>, and adjusting the <link linkend="jstemplate">generated code</link> for the preview.
 		</para>
 		<para>
 			Adding a <command>&lt;preview&gt;</command> check box is simple. Just place the following somewhere in your GUI. It will take care of all the behind-the-scenes magic of creating a preview device, updating the preview whenever the setting have changed, &etc; Example:
 		</para>
+		<note><para>Starting with version 0.6.5 of &kapp; <command>&lt;preview&gt;</command> preview elements are special-cased in plugin dialogs (not wizards): They will be placed in the button-column, irrespective of where exactly they are defined in the UI. It is still a good idea to define them at a sensible place in the layout, for backwards compatibility.
+		</para></note>
 		<programlisting>
 	&lt;document&gt;
 		[...]
 		&lt;dialog [...]&gt;
 			[...]
 			&lt;preview id="preview"/&gt;
 			[...]
 		&lt;/dialog&gt;
 		[...]
 	&lt;/document&gt;
 		</programlisting>
 		<para>
 			And that's it for the GUI definition.
 		</para>
 		<para>
 			Adjusting the JS template is a little more work. You will have to create a new function called <function>preview()</function> in addition to the <function>preprocess()</function>, <function>calculate()</function>, &etc; functions. This function should generate the code needed to produce the plot, and only that. Esp. no printing of headers, <function>rk.graphics.on()</function>, or similar calls. See the <link linkend="plot_plugin_example">example</link>, below for the typical pattern that you will use.
 		</para>
 	</sect2>
 	<sect2 id="plot_options">
 		<title>Generic plot options</title>
 		<para>
 			You will have noticed that most plotting plugins in RKWard provide a wide range of generic options &eg; for customizing axis titles or figure margins. Adding these options to your plugin is easy. They are provided by an <link linkend="embedding">embeddable</link> plugin called <command>rkward::plot_options</command>. Embed this in your plugin UI like this:
 		</para>
 		<programlisting>
 	&lt;document&gt;
 		[...]
 		&lt;logic [...]&gt;
 			&lt;connect client="plotoptions.xvar" governor="x.available"/&gt;
 			&lt;set id="plotoptions.allow_type" to="true"/&gt;
 			&lt;set id="plotoptions.allow_ylim" to="true"/&gt;
 			&lt;set id="plotoptions.allow_xlim" to="false"/&gt;
 			&lt;set id="plotoptions.allow_log" to="false"/&gt;
 			&lt;set id="plotoptions.allow_grid" to="true"/&gt;
 		&lt;/logic&gt;
 		&lt;dialog [...]&gt;
 			[...]
 			&lt;embed id="plotoptions" component="rkward::plot_options" as_button="true" label="Plot Options"/&gt;
 			[...]
 		&lt;/dialog&gt;
 		[...]
 	&lt;/document&gt;
 		</programlisting>
 		<para>
 			This will add a button to your UI to bring up a window with plot options. The logic section is just an example. It allows you some control over the plot options plugin. Read more in the plot_options plugin's help page (linked from the help page of any plugin providing the generic options).
 		</para>
 		<para>
 			Next you need to make sure that the code corresponding to your plot options is added to the generated code for your plot. To do so,
 			fetch the properties <command>code.preprocess</command>, <command>code.printout</command>, and <command>code.calculate</command> from the embedded plot options plugin, and insert them into your code as shown in the <link linkend="plot_plugin_example">example</link>, below.
 		</para>
 	</sect2>
 	<sect2 id="plot_plugin_example">
 		<title>A canonical example</title>
 		<para>
 			Here's an example .JS file that you should use as a template, whenever you create a plotting plugin:
 		</para>
 		<programlisting>
   function preprocess () {
     // the "somepackage" is needed to create the plot
     echo ("require (somepackage)\n");
   }
 
   function preview () {
     // we call all stages of the general code. Only the printout () function needs to be called slightly different for the plot preview
     preprocess ();
     // calculate (); // in this example, the plugin has no calculate () function.
     printout (true); // in this case, 'true' means: Create the plot, but not any headers or other output.
   }
   
   function printout (is_preview) {
     // If "is_preview" is set to false, it generates the full code, including headers.
     // If "is_preview" is set to true, only the essentials will be generated.
 
     if (!is_preview) {
       echo ('rk.header (' + i18n ("An example plot") + ')\n\n');
       echo ('rk.graph.on ()\n');
     }
     // only the following section will be generated for is_preview==true
 
     // remember: everything between rk.graph.on() and rk.graph.off() should be wrapped inside a try() statement:
     echo ('try ({\n');
     // insert any option-setting code that should be run before the actual plotting commands.
     // The code itself is provided by the embedded plot options plugin. printIndentedUnlessEmpty() takes care of pretty formatting.
     printIndentedUnlessEmpty ('\t', getString ("plotoptions.code.preprocess"), '', '\n');
 
     // create the actual plot. plotoptions.code.printout provides the part of the generic plot options
     // that have to be added to the plotting call, itself.
     echo ('plot (5, 5' + getString ("plotoptions.code.printout") + ')\n');
 
     // insert any option-setting code that should be run after the actual plot.
     printIndentedUnlessEmpty ('\t', getString ("plotoptions.code.calculate"), '\n');
     echo ('})'\n);  // the closure of the try() statement
 
     if (!is_preview) {
       echo ('rk.graph.off ()\n');
     }
   }
 		</programlisting>
 	</sect2>
 </sect1>
 <sect1>
 	<title>Previews for data, output and other results</title>
 	<sect2 id="preview_output">
 		<title>Previews of (HTML) output</title>
 		<note><para>This section discusses adding preview functionality to plugins creating output / HTML printouts. It is recommended that you read the separate section on <link linkend="preview_plots">plot previews</link>, before this section.</para></note>
 		<para>
 			Creating a preview of HTML output is almost the same procedure as creating a plot preview. In this case, simply make sure that the <command>preview()</command> generates the relevant
 			<command>rk.print()/rk.results()</command> commands. It is generally a good idea to omit the header statements in the preview, however. Here is a stripped-down example:
 		</para>
 		<programlisting>
 	&lt;!-- In the plugin's XML file --&gt;>
 	&lt;dialog label="Import CSV data" &gt;
 		&lt;browser id="file" type="file" label="File name"/&gt;
 		&lt;!-- [...] --&gt;>
 		&lt;preview id="preview" mode="output"/&gt;
 	&lt;/dialog&gt;>
 		</programlisting>
 		<para>
 			Note the specification of <parameter>mode="output"</parameter> in the <command>&lt;preview&gt;</command> element.
 		</para>
 		<programlisting>
 	// In the plugin's JS file
 	function preview () {
 		// generates the code used for preview
 		printout (true);
 	}
 
 	function printout (is_preview) {
 		// only generates a header if is_preview==false
 		if (!is_preview) {
 			new Header ("This is a caption").print ();
 		}
 		echo ('rk.print (result)');
 	}
 		</programlisting>
 	</sect2>
 	<sect2 id="preview_data">
 		<title>Previews of (imported) data</title>
 		<note><para>This section discusses adding preview functionality to plugins creating (importing) data. It is recommended that you read the separate section on <link linkend="preview_plots">plot previews</link>, before this section.</para></note>
 		<para>
 			Creating a preview of imported data (any type of data that <command>rk.edit()</command> can handle), is very similar to creating a <link linkend="preview_plots">plot preview</link>. The following stripped down example should help illustrate how to create a data preview:
 		</para>
 		<programlisting>
 	&lt;!-- In the plugin's XML file --&gt;>
 	&lt;dialog label="Import CSV data" &gt;
 		&lt;browser id="file" type="file" label="File name"/&gt;
 		&lt;!-- [...] --&gt;>
 		&lt;preview id="preview" active="true" mode="data"/&gt;
 	&lt;/dialog&gt;>
 		</programlisting>
 		<para>
 			Note that the <command>&lt;preview&gt;</command> element specifies <parameter>mode="data"</parameter> this time. <parameter>active="true"</parameter> simply makes the preview active by
 			default.
 		</para>
 		<programlisting>
 	// In the plugin's JS file
 	function preview () {
 		// generates the code used for preview
 		calculate (true);
 	}
 
 	function calculate (is_preview) {
 		echo ('imported &lt;- read.csv (file="' + getString ("file") /* [+ options] */);
 		if (is_preview) {
 			echo ('preview_data &lt;- imported\n');
 		} else {
 			echo ('.GlobalEnv$' + getString ("name") + ' &gt;- imported\n');
 		}
 	}
 
 	function printout () {
 		// [...]
 	}
 		</programlisting>
 		<para>
 			Again, the <command>preview()</command> function generates almost the same R code as the <command>calculate()</command> function, so we create a helper function <command>doCalcuate()</command> to factor out the common parts. The most important thing to note is that you will have to assign the imported data to a object called
 			<parameter>preview_data</parameter> (inside the current - local - environment). <emphasis>Everything else will happen automatically</emphasis> (roughly speaking, &kapp; will call <command>rk.edit(preview_data)</command>, wrapped inside a call to <command>.rk.with.window.hints()</command>).
 		</para>
 		<note><para>
 			While previews are a great feature, they do consume resources. In the case of data previews, there may be cases, where previews can cause significant performance issues. This could be
 			for importing huge datasets (which are just too large to be opened for editing in &kapp;'s editor window), but also "normal" datasets could be mis-imported, creating a huge number of rows or columns. <emphasis>It is very much recommended that you limit the <parameter>preview_data</parameter></emphasis> to a dimension that provides a useful preview, without the danger of
 			creating noticable performance issues (e.g. 50 rows by 50 columns should be more than enough in most cases).
 		</para></note>
 	</sect2>
 	<sect2 id="preview_custom">
 		<title>Custom previews</title>
 		<para>
 			The <command>&lt;preview&gt;</command> element can be used to create previews for any type of "document" window that can be attached to &kapp;'s workplace. In addition to <link linkend="preview_plots">plots</link> and <link linkend="preview_data">data windows</link>, this includes HTML files, R scripts, and object summary windows. For the latter ones, you will have to use <command>&lt;preview mode="custom"&gt;</command>.
 		</para>
 		<para>
 			If you have read the sections describing plot preview and data previews, you should have a general idea on the procedure, but "custom" previews require slightly more manual work behind the scenes. The most important R function to look at is <command>rk.assign.preview.data()</command>, here. The following short listing shows what your generated (preview) R code could look like for a plugin creating a text file output:
 		</para>
 		<programlisting>
 	## To be generated in the preview() code section of a plugin
 	pdata &lt;- rk.get.preview.data("SOMEID")
 	if (is.null (pdata)) {
 		outfile &lt;- rk.get.tempfile.name(prefix="preview", extension=".txt")
 		pdata &lt;- list(filename=outfile, on.delete=function (id) {
 			unlink(rk.get.preview.data(id)$filename)
 		})
 		rk.assign.preview.data("SOMEID", pdata)
 	}
 	try ({
 		cat ("This is a test", pdata$filename)
 		rk.edit.files(file=pdata$filename)
 	})
 		</programlisting>
 		<para>
 			Here you should get the value <parameter>SOMEID</parameter> from the <parameter>id</parameter> property of the <command>&lt;preview&gt;</command>-element. I.e. using <command>getString ("preview.id")</command> in the plugin's .js file.
 		</para>
 	</sect2>
 </sect1>
 
 <sect1 id="contextualized_plugins">
 	<title>Context-dependent plugins</title>
 	<para>
 		So far we have assumed, all plugins are always meaningful, and all placed in the main menu. However, some plugins are meaningful only (or additionally) in a certain context. For instance a plugin to export the contents of an &r; X11 graphics device is obviously most useful, when placed in the menu of an X11 device, not in the main menubar. Also, such a plugin should know about the device number that it should operate on, without having to ask the user about this.
 	</para>
 	<para>
 		We call such plugins context-dependent. Correspondingly, in the <link linkend="pluginmap">&pluginmap; file</link>, they are not (or not only) placed in the main <command>&lt;hierarchy&gt;</command> but rather into a <command>&lt;context&gt;</command> element. So far only two different contexts are supported (more will come later): x11 and file import. We'll deal with those in turn. Even if you are only interested in the import context, please also read the section on the x11 context, as this is slightly more elaborate.
 	</para>
 
 	<sect2 id="context_x11">
 		<title>X11 device context</title>
 		<para>
 			To use a plugin in the context of an x11 device - that is place it in the menubar of the window you get when you call <function>x11()</function> in the console, first declare it as usual in the <link linkend="pluginmap">&pluginmap; file</link>:
 		</para>
 		<programlisting>
 &lt;document [...]&gt;
 	&lt;components&gt;
 		[...]
 		&lt;component id="my_x11_plugin" file="my_x11_plugin.xml" label="An X11 context plugin"/&gt;
 		[...]
 	&lt;/components&gt;
 		</programlisting>
 		<para>
 			However, you do not need to define it in the hierarchy (you can, if it is also meaningful as a top-level plugin):
 		</para>
 		<programlisting>
 	&lt;hierarchy&gt;
 		[...]
 	&lt;/hierarchy&gt;
 		</programlisting>
 		<para>
 			Instead, add a definition of the "x11" context, and add it to the menus there:
 		</para>
 		<programlisting>
 	&lt;context id="x11"&gt;
 		[...]
 		&lt;menu id="edit"&gt;
 			[...]
 			&lt;entry id="my_x11_plugin"/&gt;
 		&lt;/menu&gt;
 	&lt;/context&gt;
 &lt;/document&gt;
 		</programlisting>
 		<para>
 			In the <link linkend="logic">logic section of the plugin xml</link>, you can now declare two <command>&lt;external&gt;</command> properties: <parameter>devnum</parameter> and <parameter>context</parameter>. <parameter>context</parameter> (if declared) will be set to <replaceable>"x11"</replaceable> when the plugin is invoked in this context. <parameter>devnum</parameter> will be set to the number of the graphics device to operate on. And that's all.
 		</para>
 	</sect2>
 
 	<sect2 id="context_import">
 		<title>Import data context</title>
 		<para>
 			Before reading this section, please make sure to read the section on the <link linkend="context_x11">X11 device context</link>, as that explains the basic concepts.
 		</para>
 		<para>
 			The <replaceable>"import"</replaceable> context is used to declare import file filter plugins. You simply place those in a context with <parameter>id=</parameter><replaceable>"import"</replaceable> in the &pluginmap; file. However, there is one additional twist when declaring these plugins: In order to offer a unified file selection dialog for all supported file types, you need to declare one additional bit of information on your component:
 		</para>
 		<programlisting>
 &lt;document [...]&gt;
 	&lt;components&gt;
 		[...]
 		&lt;component id="my_xyz_import_plugin" file="my_xyz_import_plugin.xml" label="Import XYZ files"&gt;
 			&lt;attribute id="format" value="*.xyz *.zyx" label="XYZ data files"/&gt;
 		&lt;/component&gt;
 		[...]
 	&lt;/components&gt;
 	&lt;hierarchy&gt;
 		[...]
 	&lt;/hierarchy&gt;
 	&lt;context id="import"&gt;
 		[...]
 		&lt;menu id="import"&gt;
 			[...]
 			&lt;entry id="my_xyz_import_plugin"/&gt;
 		&lt;/menu&gt;
 	&lt;/context&gt;
 	[...]
 &lt;/document&gt;
 		</programlisting>
 		<para>
 			The attribute line simply says, that the associate filename extensions for XYZ files are <literal role="extension">*.xyz</literal> or <literal role="extension">*.zyx</literal>, and that the filter should be labelled <quote>XYZ data files</quote> in the file selection dialog.
 		</para>
 		<para>
 			You can declare two <command>&lt;external&gt;</command> properties in your plugin. <parameter>filename</parameter> will be set to the selected file name, and <parameter>context</parameter> will be set to <replaceable>"import"</replaceable>.
 		</para>
 	</sect2>
 </sect1>
 
 <sect1 id="querying_r_for_info">
 <title>Querying R for information</title>
 	<para>In some cases, you may want to fetch further information from R, to be presented in your plugin's UI. For instance, you may want to offer a selection of the levels of a factor that the user
 	has selected for analysis. Since version 0.6.2 or &rkward; it is possible to do so. Before we start, it is important that you are aware of some caveats:</para>
 	<para>R Code run from inside the plugin's UI logic is evaluated in R's event loop, meaning they can be run <emphasis>while</emphasis> other computations are running. This is to make sure your plugin's UI will be usable, even while R is busy doing other things. However, this makes it really important, that your code does not have side effects. In particular:</para>
 	<itemizedlist>
 		<listitem><para>Do <emphasis>not</emphasis> make any assignments in .GlobalEnv or any other non-local environment.</para></listitem>
 		<listitem><para>Do <emphasis>not</emphasis> print anything to the output file.</para></listitem>
 		<listitem><para>Do <emphasis>not</emphasis> plot anything on-screen.</para></listitem>
 		<listitem><para>In general, do <emphasis>not</emphasis> do anything that has side-effects. Your code may <emphasis>read in information</emphasis>, not "<emphasis>do</emphasis>" anything.</para></listitem>
 	</itemizedlist>
 	<para>With this in mind, here's the general pattern. You will use this inside a <link linkend="logic_scripted">scripted UI logic</link> section:</para>
 	<programlisting>
 		&lt;script&gt;&lt;![CDATA[
 				last_command_id = -1;
 				gui.addChangeCommand ("variable", "update ()");
 				update = function () {
 					gui.setValue ("selector.enabled", 0);
 					variable = gui.getValue ("variable");
 					if (variable == "") return;
 
 					last_command_id = doRCommand ('levels (' + variable + ')', "commandFinished");
 				}
 
 				commandFinished = function (result, id) {
 					if (id != last_command_id) return;  // another result is about to arrive
 					if (typeof (result) == "undefined") {
 						gui.setListValue ("selector.available", Array ("ERROR"));
 						return;
 					}
 					gui.setValue ("selector.enabled", 1);
 					gui.setListValue ("selector.available", result);
 				}
 		]]&gt;&lt;/script&gt;
 	</programlisting>
 	<para>Here, <parameter>variable</parameter> is a property holding an object name (&eg; inside a <command>&lt;varslot&gt;</command>). Whenever that changes, you will want to update the display
 	      of levels inside the <command>&lt;valueselector&gt;</command>, named <parameter>selector</parameter>. The key function here is <command>doRCommand()</command>, taking as first parameter
 		  the command string to run, and as second parameter the name of a function to call, when the command has finished. Note that the command is running asynchronously, and this makes things
 		  a bit more complex. For one thing you want to make sure, that your <command>&lt;valueselector&gt;</command> remains disabled, while it does not contain up-to-date information. Another
 		  thing is that you could potentially have queued more than one command, before you get the first results. This is why every command is given an "id", and we store that in <parameter>last_command_id</parameter> for later reference.</para>
 	  <para>When the command is done, the specified callback is called (<parameter>commandFinished</parameter>, in this case) with two parameters: The result itself, and the id of the corresponding
 		  command. The result will be of a type resembling the representation in R, &ie; a numeric Array, if the result is numeric, &etc; It can even be an R <command>list()</command>, but in this case
 		  it will be represented as a JS <command>Array()</command> without names.</para>
 	  <para>Note that even this example is somewhat simplified. In reality you should take additional precautions, &eg; to avoid putting an extreme amount of levels into the selector. The good news
 		  is that probably you do not have to do all this yourself. The above example is taken from the <command>rkward::level_select</command> plugin, for instance, which you can simply <link linkend="embedding">embed</link> in your own
 		  plugin. This even allows you to specify a different expression to run in place of <command>levels()</command>.</para>
 </sect1>
 
 <sect1 id="current_object">
 <title>Referencing the current object</title>
 	<para>
 		For many plugins it is desirable to work on the <quote>current</quote> object. For instance a <quote>sort</quote> plugin could pre-select the data.frame that is currently being edited for sorting. The name of the current object is available to plugins as a pre-defined property called <parameter>current_object</parameter>. You can connect to this property in the usual way. If no object is current, the property equates to an empty string.
 	</para>
 	<para>
 		Currently the <parameter>current_object</parameter> can only be of class <function>data.frame</function>, but please do not rely on this, since this will be extended to other types of data in the future. If you are interested in <function>data.frame</function> objects, only, connect to the <parameter>current_dataframe</parameter> property, instead. Alternatively, you can enforce type requirements by using appropriate constraints on your <command>&lt;varslot&gt;</command>s, or by using <link linkend="logic_scripted">GUI logic scripting</link>.
 	</para>
 </sect1>
 
 <sect1 id="optionset">
 	<title>Repeating (a set of) options</title>
 	<para>
 		Sometimes you want to repeat a set of options for an arbitrary number of items. E.g. suppose you want to implement a plugin for sorting a data.frame. You may want to allow for sorting by an arbitrary number of columns (in case of ties among the first column(s)). This could simply be realized by allowing the user to select multiple variables in a <command>&lt;varslot&gt;</command> with <parameter>multi="true"</parameter>. But if you want to extend this, &eg; allowing the user to specify for each variable whether it should be converted to character / numeric, or whether sorting should be ascending or descending, you need more flexibility. Other examples would be plotting multiple lines in one plot (allowing to select object, line style, line color, &etc; for each line), or specifying a mapping for recoding from a set of old values to new values.
 	</para>
 	<para>
 		Enter the <command>&lt;optionset&gt;</command>. Let's look at a simple example, first:
 	</para>
 		<programlisting>
 &lt;dialog [...]&gt;
 	[...]
 	&lt;optionset id="set" min_rows="1"&gt;
 		&lt;content&gt;
 			&lt;row&gt;
 				&lt;input id="firstname" label="Given name(s)" size="small"&gt;
 				&lt;input id="lastname" label="Family name" size="small"&gt;
 				&lt;radio id="gender" label="Gender"&gt;
 					&lt;optioncolumn label="Male" value="m"/&gt;
 					&lt;optioncolumn label="Female" value="f"/&gt;
 				&lt;/radio&gt;
 			&lt;/row&gt;
 		&lt;/content&gt;
 
 		&lt;optioncolumn id="firstnames" label="Given name(s)" connect="firstname.text"&gt;
 		&lt;optioncolumn id="lastnames" label="Family name" connect="lastname.text"&gt;
 		&lt;optioncolumn id="gender" connect="gender.string"&gt;
 	&lt;/optionset&gt;
 	[...]
 &lt;/dialog&gt;
 		</programlisting>
 	<para>
 		Here, we created a UI for specifying a number of persons (&eg; authors). The UI requires at least one entry (<parameter>min_rows="1"</parameter>). Inside the <command>&lt;optionset&gt;</command>-element, we begin by specifying the
 		<command>&lt;content&gt;</command>, &ie; those elements that belong to the option set. You will be familiar with most elements
 		inside the <command>&lt;content&gt;</command>.
 	</para><para>
 		Next we specify the variables of interest that we will want to read from the option set in our JS file. As we will be dealing with
 		an arbitrary number of items, we cannot just read <function>getString ("firstname")</function> in JS. Rather, for each value of
 		interest, we specify an <command>&lt;optioncolumn&gt;</command>. For the first optioncolumn in the example, <command>&lt;connect="firstname.text"&gt;</command> means that the content of the <command>&lt;input&gt;</command>
 		element "firstname" is read for each item. <command>&lt;optioncolumn&gt;</command>s for which a <parameter>label</parameter> is given,
 		will be shown in the display, in a column by that label. In JS, we can now fetch the first names for all authors using <function>getList("set.firstname")</function>, <function>getList("set.lastnames")</function> for the family
 		names, and <function>getList("set.gender")</function> for an array of "m"/"f" strings.
 	</para>
 	<para>
 		Note that there are no restrictions on what you can place inside an <command>&lt;optionset&gt;</command>. You can even use <link linkend="embedding">embedded</link> components. Just as with any other element, all you have to do is to collect the output
 		variables of interest in an <command>&lt;optioncolumn&gt;</command>-specification. In the case of embedded plugins, this is often a section of the "code" property. E.g.:
 	</para>
 		<programlisting>
 &lt;dialog [...]&gt;
 	[...]
 	&lt;optionset id="set" min_rows="1"&gt;
 		&lt;content&gt;
 			[...]
 			&lt;embed id="color" component="rkward::color_chooser" label="Color"/&gt;
 		&lt;/content&gt;
 
 		[...]
 		&lt;optioncolumn id="color_params" connect="color.code.printout"&gt;
 	&lt;/optionset&gt;
 	[...]
 &lt;/dialog&gt;
 		</programlisting>
 	<para>
 		Of course you can also use <link linkend="logic">UI logic</link> inside an optionset. There are two options for doing this: You can do so	by making connection (or scripting) in the main <command>&lt;logic&gt;</command> section of your plugin, as usual. However, you will access the UI elements in the contents region as (&eg;) "set.contents.firstname.XYZ". Note the prefix "set" (the <parameter>id</parameter> you have assigned to the set and "contents". Alternatively, you can add a separate <command>&lt;logic&gt;</command> section as a child element of your <command>&lt;optionset&gt;</command>. In this case, <parameter>id</parameter>s will be addressed relative to the contents region, &eg; "firstname.XYZ". Only the <command>&lt;script&gt;</command>-element is not allowed in the logic section of an optionset. If you want to use scripting,
 		you will have to utilize the plugin's main <command>&lt;logic&gt;</command> section.
 	</para>
 	<note>
 		<para>
 			When scripting logic in an optionset, all you can do is access the <emphasis>current</emphasis> content region. Thus, typically,
 			it is only meaningful to connect elements inside the contents region to each other. Connecting a property outside the <command>&lt;optionset&gt;</command> to a property inside the content region, may be useful for initialization. However,
 			modifying the contents region after initialization will <emphasis>not</emphasis> apply to items that the user has already
 			defined. Only to the currently selected item in the set.
 		</para>
 	</note>
 	<sect2 id="optionset_driven">
 		<title>"Driven" optionsets</title>
 		<para>
 			So far we have considered an <command>&lt;optionset&gt;</command> that provides buttons for adding / removing items. However,
 			in some cases, it is much more natural to select items outside the <command>&lt;optionset&gt;</command>, and only provide
 			options for customizing some aspects of each item in an <command>&lt;optionset&gt;</command>. E.g. suppose you want to allow
 			the user to plot several objects inside one plot. For each object, the user should be able to specify line color.
 			You <emphasis>could</emphasis> solve this by placing a <command>&lt;varselector&gt;</command> and
 			<command>&lt;varslot&gt;</command> inside the <command>&lt;content&gt;</command> area, allowing the user to select one item
 			at a time. However, it will mean much less clicks for the user, if you use a <command>&lt;varslot multi="true"&gt;</command>
 			<emphasis>outside</emphasis> the <command>&lt;optionset&gt;</command>, instead. Then you will connect this selection of objects
 			to a so-called "driven" optionset. Here's how:
 		</para>
 		<programlisting>
 &lt;dialog [...]&gt;
 	&lt;logic&gt;
 		&lt;connect client="set.vars" governor="vars.available"/&gt;
 		&lt;connect client="set.varnames" governor="vars.available.shortname"/&gt;
 	&lt;/logic&gt;
 	[...]
 	&lt;varselector id="varsel"/&gt;
 	&lt;varslot id="vars" label="Objects to plot"/&gt;
 	&lt;optionset id="set" keycolumn="var"&gt;
 		&lt;content&gt;
 			[...]
 			&lt;embed id="color" component="rkward::color_chooser" label="Line color"/&gt;
 		&lt;/content&gt;
 
 		[...]
 		&lt;optioncolumn id="vars" external="true"&gt;
 		&lt;optioncolumn id="varnames" external="true" label="Variable"&gt;
 		&lt;optioncolumn id="color_params" connect="color.code.printout"&gt;
 	&lt;/optionset&gt;
 	[...]
 &lt;/dialog&gt;
 		</programlisting>
 		<para>
 			We'll start looking at the example at the bottom. You'll note that two <command>&lt;optioncolumn&gt;</command> specifications have
 			<parameter>external="true"</parameter>. This tells &rkward; that these are controlled from outside the <command>&lt;optionset&gt;</command>. Here, the sole purpose of the "varnames"-optioncolumn is to provide easy-to-read labels in the
 			optionset display (it is connected to the "shortname" modifier of the property holding the selected
 			objects). The purpose of the "vars"-optioncolumn is to serve as the "key" column, as specified by
 			<command>&lt;optionset keycolumn="vars"...&gt;</command>. This means that for each entry in this list, the set will offer
 			one set of options, and options are logically tied to these entries. This column is connected to the property holding the
 			selected objects in the <command>&lt;varslot&gt;</command>. That is for each object that is selected there, the <command>&lt;optionset&gt;</command> will allow to specify line color.
 		</para>
 		<note>
 			<para>
 				External column can also be <parameter>connect</parameter>ed to properties inside the
 				<command>&lt;content&gt;</command> region. However, it is important to note that optioncolumns declared
 				<parameter>external="true"</parameter> should never be modified from inside the <command>&lt;optionset&gt;</command>, and
 				optioncolumns declared <parameter>external="false"</parameter> (the default) should never be modified from outside the
 				<command>&lt;optionset&gt;</command>.
 			</para>
 		</note>
 	</sect2>
 	<sect2 id="optionset_alternatives">
 		<title>Alternatives: When not to use optionsets</title>
 		<para>
 			Optionsets are a powerful tool, but they can sometimes do more harm than good, as they add considerable complexity, both
 			from the perspective of a plugin developer, and from the perspective of a user. Thus, think twice, when using them. Here's
 			some advice:
 		</para>
 		<itemizedlist>
 			<listitem><para>For some simple cases, the <command>&lt;matrix&gt;</command> element may provide a useful lightweight alternative.</para></listitem>
 			<listitem><para>Don't make your plugin do too much. We gave the example of using an optionset for a plugin to
 			draw several lines within one plot. But in general it is not a good idea to create a plugin that will produce individual
 			plots for each item in an optionset. Rather make the plugin produce one plot, and the user can call it multiple times.
 			</para></listitem>
 			<listitem><para>If you don't expect more than two or three items in a set, consider repeating the options, manually,
 			instead.</para></listitem>
 		</itemizedlist>
 	</sect2>
 </sect1>
 
 </chapter>
 
 <chapter id="chapter_dependencies">
 <title>Handling dependencies and compatibility issues</title>
 <sect1 id="sect_dependencies_rkward_version"><title>&rkward; version compatibility</title>
 	<para>We do our best to make sure that plugins developed for an old version of &rkward; will remain functional in later versions of &rkward;.  However, the reverse is not always true as new features are been added. Since not all users are running the latest version of &rkward;, this means your plugin may not work for everybody.</para>
 	<para>When you are aware of such compatibility issues, you should make sure to document this fact in your &pluginmap; file, using the <command>&lt;dependencies&gt;</command> element. The <command>&lt;dependencies&gt;</command> can either be specified as a direct child of the &pluginmap;'s &lt;document&gt; element, or as a child element of individual <command>&lt;component&gt;</command> definitions. In the first case, the dependencies apply to <emphasis>all</emphasis> plugins in the map. In the latter case only to the individual <command>&lt;component&gt;</command>(s). You can also mix top "global" and "specific" dependencies. In this case the "global" dependencies are added to those of the individual component.</para>
 	<para>Let's look at a small example:</para>
 	<programlisting>
 &lt;document ...&gt;
 	&lt;dependencies rkward_min_version="0.5.0c" /&gt;
 	&lt;components ...&gt;
 		&lt;component id="myplugin" file="reduced_version_of_myplugin.xml" ...&gt;
 			&lt;dependencies rkward_max_version="0.6.0z" /&gt;
 		&lt;/component&gt;
 		&lt;component id="myplugin" file="fancy_version_of_myplugin.xml" ...&gt;
 			&lt;dependencies rkward_min_version="0.6.1" /&gt;
 		&lt;/component&gt;
 		...
 x	&lt;/components ...&gt;
 &lt;/document&gt;
 	</programlisting>
 	<para>In this example, all plugins are known to require at least version 0.5.0c of &rkward;. One plugin, with <replaceable>id="myplugin"</replaceable> is provided in two alternative variants. The first, stripped down, version will be used for &rkward; versions before 0.6.1. The latter utilizes features that are new in &rkward; 0.6.1, and will only be used from &rkward; 0.6.1 onwards.</para>
 	<para>Providing alternative variants like this is a very user friendly way to make use of new features, while still keeping support for earlier versions of &rkward;. Alternative versions should share the same <parameter>id</parameter> (warnings will be produced, otherwise), and may only be defined <emphasis>within the same</emphasis> &pluginmap; file.</para>
 	<para>Plugin which are not compatible with the running version of &rkward;, and which do not come with an alternative version will be ignored with a warning.</para>
 	<note><para>Actually &rkward; 0.6.1 is the first version to interpret dependencies - and to report dependency errors - at all. Thus, contrary to what the example may suggest, specifying any earlier versions in the dependencies will not have any direct effect (but may still be a good idea for documentation purposes).</para></note>
 	<para><emphasis>Sometimes</emphasis> it will even be possible to handle version incompatibility issues <emphasis>inside</emphasis> a single &pluginmap; file, using the <command>&lt;dependency_check&gt;</command> element, described in the following section.</para>
 </sect1>
 <sect1 id="sect_dependencies_r_version"><title>&r; version compatibility</title>
 	<para>Similar to <parameter>rkward_min_version</parameter> and <parameter>rkward_max_version</parameter>, the <command>&lt;dependencies&gt;</command> element allows specification of the attributes <parameter>R_min_version</parameter> and <parameter>R_max_version</parameter>. However, there are the following differences:</para>
 	<itemizedlist>
 		<listitem><para>Plugins which fail to meet the &r; version requirement are <emphasis>not</emphasis> currently skipped when reading a &pluginmap; file. The user can still call the plugin, and will not see any immediate warning (in future versions, a warning message will probably be shown)</para></listitem>
 		<listitem><para>In consequence it is also <emphasis>not</emphasis> possible to define alternative versions of a plugin depending on the running version of &r;.</para></listitem>
 		<listitem><para>However, it is often easy to achieve backwards compatibility as shown below. If you are aware of &r; compatibility issues, please consider using this method, instead of defining a dependency on a particular version of &r;.</para></listitem>
 	</itemizedlist>
 	<para>In many cases, it is easily possible to provide reduced functionality, if a certain feature is not available in the running version of &r;. Consider the following short example of a plugin .xml file:</para>
 	<programlisting>
 &lt;dialog [...]&gt;
 	&lt;logic&gt;
 		&lt;dependency_check id="ris210" R_min_version="2.10.0"/&gt;
 		&lt;connect client="compression.xz.enabled" governor="ris210"/&gt;
 	&lt;/logic&gt;
 	[...]
 	&lt;radio id="compression" label="Compression method"&gt;
 		&lt;option label="None" value=""&gt;
 		&lt;option label="gzip" value="gzip"&gt;
 		&lt;option id="xz" label="xz" value="xz"&gt;
 	&lt;/radio&gt;
 	[...]
 &lt;/dialog&gt;
 	</programlisting>
 	<para>In this example the compression option "xz" will simply be disabled when the &r; runtime version is older than 2.10.0 (which did not support xz compression). The <command>&lt;dependency_check&gt;</command> element supports the same attributes as the <command>&lt;dependencies&gt;</command> element in &pluginmap; files. It creates a boolean property, which is true, if the specified dependencies are met, false otherwise.</para>
 </sect1>
 <sect1 id="sect_dependencies_r_packages"><title>Dependencies on &r; packages</title>
 <para>Dependencies on specific &r; packages can be defined, but as of &rkward; 0.6.1, these dependencies are neither checked, nor installed / loaded, automatically. They are shown in the plugin help files, however. Here is an example definition:</para>
 <programlisting>
 	&lt;dependencies&gt;
 		&lt;package 
 			name="heisenberg"
 			min_version="0.11-2"
 			repository="http://rforge.r-project.org"
 		/&gt;
 	&lt;/dependencies&gt;
 </programlisting>
 <note><para>Always make sure to add appropriate <function>require()</function> calls, if you plugin needs certain packages to be loaded.</para></note>
 <note><para>If you <link linkend="external_plugins">distribute your &pluginmap; as an &r; package</link>, and all plugins depend on a particular package, then you should define that dependency on the &r; package level. Defining dependencies to &r; packages on the level of the &rkward; &pluginmap; is most useful, if only some of your plugins need the dependency, the dependency is not available from CRAN, or your &pluginmap; is not distributed as an &r; package.</para></note>
 </sect1>
 <sect1 id="sect_dependencies_other_pluginmaps"><title>Dependencies on other &rkward; &pluginmap;s</title>
 	<para>If your plugins depend on plugins defined in another &pluginmap; (that is <emphasis>not</emphasis> part of your package) you can define this dependency like this:</para>
 <programlisting>
 	&lt;dependencies&gt;
 		&lt;pluginmap 
 			name="heisenberg_plugins"
 			url="http://eternalwondermaths.example.org/hsb"
 		/&gt;
 	&lt;/dependencies&gt;
 </programlisting>
 <para>Currently will neither load, nor install, nor even warn about missing &pluginmap;s, but at least information on dependencies (and where to obtain them) will be shown on the plugin's help page. You do not have to (and you should not) declare dependencies on &pluginmap;s that are shipped with the official &rkward; distribution, or on &pluginmap;s that are inside your own package. Further, if a required &pluginmap; is <link linkend="external_plugins">distributed as an &r; package</link>, declare a dependency of the package (as shown in the previous section), rather than on the map.</para>
 	<para>To make sure that required &pluginmap;s are actually loaded, use the <command>&lt;require&gt;</command>-tag (refer to the <link linkend="pluginmapelements">reference</link> for details).</para>
 </sect1>
 <sect1 id="sect_dependencies_example"><title>An example</title>
 	<para>To clarify how dependency definitions can be mixed, here's a combined example:</para>
 <programlisting>
 &lt;document ...&gt;
 	&lt;dependencies rkward_min_version="0.5.0c"&gt;
 		&lt;package 
 			name="heisenberg"
 			min_version="0.11-2"
 			repository="http://rforge.r-project.org"
 		/&gt;
 		&lt;package 
 			name="DreamsOfPi"
 			min_version="0.2"
 		/&gt;
 		&lt;pluginmap 
 			name="heisenberg_plugins"
 			url="http://eternalwondermaths.example.org/hsb"
 		/&gt;
 	&lt;dependencies&gt;
 
 	&lt;require map="heisenberg::heisenberg_plugins"/&gt;
 
 	&lt;components ...&gt;
 		&lt;component id="myplugin" file="reduced_version_of_myplugin.xml" ...&gt;
 			&lt;dependencies rkward_max_version="0.6.0z" /&gt;
 		&lt;/component&gt;
 		&lt;component id="myplugin" file="fancy_version_of_myplugin.xml" ...&gt;
 			&lt;dependencies rkward_min_version="0.6.1" /&gt;
 		&lt;/component&gt;
 		...
 x	&lt;/components ...&gt;
 &lt;/document&gt;
 </programlisting>
 </sect1>
 </chapter>
 
 <chapter id="i18n">
 	<title>Plugin translations</title>
 	<para>
 		So far we have used a few concepts regarding translations or "i18n" (short for "internationaliation", which has 18 characters between i and n) in passing. In this chapter we
 		give a more in-depth account of what i18n functionally for &rkward; plugins. For the most part you will <emphasis>not</emphasis> need all of this in your plugins. However,
 		it may be a good idea to read over this chapter in full, as understanding these concept should help you creating plugins that are fully translatable, and that allow for a high
 		quality of translations.
 	</para>
 	<sect1 id="i18n_general"><title>General considerations</title>
 		<para>
 			One important point to understand about software translations, in contrast to translations of other text materials, is that translators will often have a rather hard
 			time getting a complete picture of <emphasis>what</emphasis> they are translating. Software translations are necessarily based on rather short fragments of text: Every
 			label you give to an <command>&lt;option&gt;</command> in a <command>&lt;radio&gt;</command>, every string that you mark for translation in an
 			<command>i18n()</command>-function call, will form a separate "translation unit". In essence, each such fragment will be presented to the translator in isolation. Well,
 			not complete isolation, as we do try to provide translator with as much meaningful context as can be extracted, automatically. But at some points translators will need
 			additional context to make sense of a string, especially where strings are short.
 		</para>
 	</sect1>
 	<sect1 id="i18n_xml"><title>i18n in &rkward;'s xml files</title>
 		<para>
 			For &rkward;'s xml files, i18n will mostly just work. If you are writing your own <command>.pluginmap</command> (&eg; for an <link linkend="external_plugins">external plugin</link>),
 			you will have to specify a <replaceable>po_id</replaceable> next to the pluginmap's <replaceable>id</replaceable>. This defines the "message catalog" to use. In general this should
 			be set identical to the <replaceable>id</replaceable> of your <command>.pluginmap</command>, but if you provide several <command>.pluginmap</command>s and want to control, how
 			message catalogs are divided up, this allows you to do so. The <replaceable>po_id</replaceable> is inherited by any <command>.pluginmap</command> you include, unless that declares
 			a different <replaceable>po_id</replaceable>, and by all plugins declared in it.
 		</para>
 		<para>
 			For plugins and help pages, you do not need to tell &rkward; which strings are to be translated, because that is generally evident from their usage. However, as explained above,
 			you should keep an eye out for strings that may be ambiguous or need some explaining in order to be translated, correctly. For strings that could have different meanings, provide
 			an <replaceable>i18n_context</replaceable> like this:
 		</para>
 		<programlisting>
 &lt;checkbox id="scale" label="Scale" i18n_context="Show the scale"/&gt;
 &lt;checkbox id="scale" label="Scale" i18n_context="Scale the plot"/&gt;
 		</programlisting>
 		<para>
 			Providing <replaceable>i18n_context</replaceable> will cause the two strings to be translated separately. Otherwise they would share a single translation. In addition, the context
 			is shown to the translator. The <replaceable>i18n_context</replaceable>-attribute is supported on all elements that can have translatable strings, somewhere, including elements that
 			contain text inside them (&eg; <command>&lt;text&gt;</command>-elements).
 		</para>
 		<para>
 			In other cases the string to translate has a single non-ambiguous meaning, but may still need some explaining. In this case you can add a comment that will be shown to translators.
 			Examples might include:
 		</para>
 		<programlisting>
 &lt;!-- i18n: No, this is not a typo for screen plot! --&gt;
 &lt;component id="scree_plot" label="Scree plot"/&gt;
 
 &lt;!-- i18n: If you can, please make this string short. Having more than some 15 chars
 looks really ugly at this point, and the meaning should be mostly self-evident to the
 user (selection from a list of values shown next to this element) --&gt;
 &lt;valueslot id="selected" label="Pick one"/&gt;
 		</programlisting>
 		<para>
 			Note that such comments must precede the element they apply to, and must start with either "i18n:" or "TRANSLATORS:".
 		</para>
 		<para>
 			Finally, in rare cases, you may want to exclude certain strings from translation. This may make sense, for example, if you offer a choice between
 			several R function names in a <command>&lt;radio&gt;</command>-control. You do not want these to be translated, then (but depending on the context, 
 			you should consider giving a descriptive label, instead):
 		</para>
 		<programlisting>
 &lt;radio id="transformation" label="R function to apply"&gt;
   &lt;option id="as.list" noi18n_label="as.list()"/&gt;
   &lt;option id="as.vector" noi18n_label="as.vector()"/&gt;
   [...]
 &lt;/radio&gt;
 		</programlisting>
 		<para>
 			Note that you will omit the <replaceable>label</replaceable>-attribute, then, and specify <replaceable>noi18n_label</replaceable>, instead. Also, note that in contrast to
 			<replaceable>i18n_context</replaceable> and comments, using <replaceable>noi18n_label</replaceable> will make your plugin incompatible with versions of &rkward; prior to 0.6.3.
 		</para>
 	</sect1>
 	<sect1 id="i18n_js"><title>i18n in &rkward;'s js files and sections</title>
 		<para>
 			In contrast to the .xml files, making the js files of a plugin translatable requires more custom work. The key difference, here, is that there is no decent automatic way to tell,
 			whether a string is meant to be displayed as a human readable string, or a piece of code. So you need to mark this up, yourself. We have already shown examples of this, all along. Here
 			is a more complete description of the i18n-functions available in js code, and some hints for more complex cases:
 		</para>
 <variablelist>
 <varlistentry>
 	<term><command>i18n (msgid, [...])</command></term>
 	<listitem><para>The most important function. Marks the string for translation. The string (whether translated or not) is returned quoted using double quotes ('"'). An arbitrary
 			number of placeholders can be used in the string like shown below. Using such placeholders instead of concatenating small substrings is much easier for translators.:</para>
 		<programlisting>
 			i18n ("Compare objects %1 and %2", getString ('x'), getString ('y'));
 		</programlisting></listitem>
 </varlistentry>
 <varlistentry>
 	<term><command>i18nc (msgctxt, msgid, [...])</command></term>
 	<listitem><para>Same as <command>i18n()</command>, but additionally providing a message context:</para>
 		<programlisting>
 			i18nc ("proper name, not state of mind", "Mood test");
 		</programlisting></listitem>
 </varlistentry>
 <varlistentry>
 	<term><command>i18np (msgid_singular, msgid_plural, n, [...])</command></term>
 	<listitem><para>Same as <command>i18n()</command>, but for messages that may be different in singular or plural form (and some languages have differentiate yet more numerical forms). Note
 			that just like with <command>i18n()</command>, you can use an arbitrary number of replacements, but the first ('%1') is required, and has to be an integer.</para>
 		<programlisting>
 			i18np ("Comparing a single pair", "Comparing %1 distinct pairs", n_pairs);
 		</programlisting></listitem>
 </varlistentry>
 <varlistentry>
 	<term><command>i18ncp (msgctxt, msgid_singular, msgid_plural, n, [...])</command></term>
 	<listitem><para><command>i18np()</command> with added message context.</para></listitem>
 </varlistentry>
 <varlistentry>
 	<term><command>comment (comment, [indentation])</command></term>
 	<listitem><para>Echos a code comment, marked for translation. In contrast to the other i18n() functions, this is not quoted, but a '#' is added to each line of the comment.</para>
 		<programlisting>
 			comment ("Transpose the matrix");
 			echo ('x &lt;- t (x)\n');
 		</programlisting></listitem>
 </varlistentry>
 </variablelist>
 	<para>
 		To add comments to the translators (see <link linkend="i18n_xml">above</link> for a discussion of the differences between comment and context), add a comment starting with "i18n:" or
 		"translators:" directly above the <command>i18n()</command>-call to comment. E.g.:
 	</para>
 	<programlisting>
 		// i18n: Spelling is correct: Scree plot.
 		echo ('rk.header (' + i18n ("Scree plot") + ')\n');
 	</programlisting>
 
 		<sect2 id="i18n_js_quoting"><title>i18n and quotes</title>
 			<para>
 				For the most part, you will not have to worry about i18n() behavior with respect to quotes. As, typically, translatable strings are string literals, quoting them is just the
 				right thing to do, and saves you some typing. Also, in functions like <command>makeHeaderCode()/Header()</command> that usually quote their arguments, i18n()'ed strings are protected
 				from duplicate quoting. Essentially, this works, by sending the translated string first through <command>quote()</command> (to make it quoted), then through
 				<command>noquote()</command> (to protect it from additional quoting). Should you require a translatable string that is not quoted, use <command>i18n(noquote ("My message"))</command>.
 				Should you require a translatable string to be quoted, a second time, send it through <command>quote()</command>, <emphasis>twice</emphasis>.
 			</para>
 			<para>
 				That said, it is generally not a good idea to make bits like function names or variable names translatable. For one thing, R, the programming language, is inherently in English,
 				and there is no internationalization of the language itself. Code comments are a different beast, but you should use the <command>comment()</command>-function for those. Secondly,
 				making syntactically relevant parts of the generated code translatable means that translations could actually break your plugin.
 				E.g. if an unsuspecting translator translates a string meant as a variable name in two distinct words with a space in between.
 			</para>
 		</sect2>
 
 		<sect2 id="i18n_js_compatibility"><title>i18n and backwards compatibility</title>
 			<para>
 				One unfortunate aspect of the lack of <command>i18n()</command>-support in &rkward; versions up to 0.6.2 is that adding <command>i18n()</command> calls will make the plugin require
 				&rkward; version 0.6.3. If your plugin is developed outside &rkward;'s official release, this may be a problem. Here are some possible options on how to handle this:
 			</para>
 		<itemizedlist>
 			<listitem><para>Provide the plugin in two versions for &rkward; &gt;= 0.6.3 and &rkward; &lt; 0.6.3, as described in the chapter on 
 					<link linkend="sect_dependencies_rkward_version">handling dependencies</link></para></listitem>
 			<listitem><para>Simply don't translate the strings in the .js-file, yet. Obviously this is an easy, but rather inelegant solution.</para></listitem>
 			<listitem><para>Include some support code in your .js-file(s) like shown below:</para></listitem>
 		</itemizedlist>
 		<programlisting>
 			// js-function "comment" was not defined before 0.6.3
 			if (typeof (comment) == 'undefined) {
 				// define function i18n(), and any others you may need. Note that your implementation could actually be simpler than
 				// shown, here, &eg; if you do not make use of placeholders.
 				i18n = function (msgid) {
 					var ret = msgid;
 					for (var i = 1; i &lt; arguments.length; i++) {
 						ret = ret.replace(new RegExp("%" + i, 'g'), arguments[i]);
 					}
 					if (msgid.noquote) {
 						ret.noquote = msgid.noquote;
 						return (ret);
 					}
 					return (noquote (quote (ret)));
 				}
 			}
 		</programlisting>
 		</sect2>
 	</sect1>
 	<sect1 id="i18n_workflow"><title>Translation maintainance</title>
 		<para>
 			Now that you have made your plugin translatable, how do you actually get it translated? In general you only need to worry about this, when developing an <link linkend="external_plugins">
 			external plugin</link>. For plugins in &rkward;'s main repository, all the magic is done for you. Here's the basic workflow. Note that you need the "gettext" tools, installed:
 		</para>
 		<itemizedlist>
 			<listitem><para>Mark up all strings, providing context and comments as needed</para></listitem>
 			<listitem><para>Run <command>python scripts/update_plugin_messages.py --extract-only /path/to/my.pluginmap</command>. scripts/update_plugin_messages.py is not currently part of the source
 					releases, but can be found in a source repository checkout.</para></listitem>
 			<listitem><para>Distribute the resulting <command>rkward__<replaceable>POID</replaceable>.pot</command> file to your translators. For external plugins, it is recommended to place it
 					in a subfolder "po" in inst/rkward.</para></listitem>
 			<listitem><para>Translator opens the file in a translation tool such as <command>lokalize</command>. Actually, even if you are not going to prepare any translation, yourself, 
 					you should try this step for yourself. Browse the extracted strings looking out for problems / ambiguities.</para></listitem>
 			<listitem><para>Translator saves the translation as <command>rkward__<replaceable>POID</replaceable>.<replaceable>xx</replaceable>.po</command> (where
 					<replaceable>xx</replaceable> is the language code), and sends it back to you.</para></listitem>
 			<listitem><para>Copy <command>rkward__<replaceable>POID</replaceable>.<replaceable>xx</replaceable>.po</command> to your sources, next to
 					<command>rkward__<replaceable>POID</replaceable>.pot</command>. Run <command>python scripts/update_plugin_messages.py /path/to/my.pluginmap</command> (Note: without
 					<replaceable>--extract-only</replaceable>, this time). This will merge the translation with any interim string changes, compile the translation, and install it into
 					<command><replaceable>DIR_OF_PLUGINMAP</replaceable>/po/<replaceable>xx</replaceable>/LC_MESSAGES/rkward__<replaceable>POID</replaceable>.mo</command> (where
 					<replaceable>xx</replaceable> is the language code, again).</para></listitem>
 			<listitem><para>You should also include the non-compiled translation (&ie; <command>rkward__<replaceable>POID</replaceable>.<replaceable>xx</replaceable>.po</command>) in
 					your distribution, in the "po" subdirectory.</para></listitem>
       <listitem><para>For any update of your plugin, run <command>python scripts/update_plugin_messages.py /path/to/my.pluginmap</command> to update the .pot file, but also the
 					existing .po-files, and the compiled message catalogs.</para></listitem>
 		</itemizedlist>
 	</sect1>
 	<sect1 id="i18n_translators"><title>Writing plugin translations</title>
 		<para>
 			We assume you know your trade as a translator, or are willing to read up on it, elsewhere. A few words specifically about translations of RKWard plugins, though:
 		</para>
 		<itemizedlist>
 			<listitem><para>RKWard plugins were not translatable until version 0.6.3, and were mostly not written with i18n in mind, before then. Thus you are going to encounter rather
 					more ambiguous strings, and other i18n problems than in other mature projects. Please don't just silently work around these, but let us (or the plugin maintainers) 
 					know, so we can fix these issues.</para></listitem>
 			<listitem><para>Many RKWard plugins refer to highly specialized terms, from data handling and statistics, but also from other fields of science. In many cases, a good translation
 					will require at least basic knowledge of these fields. In some cases, there <emphasis>is</emphasis> no good translation for a technical term, and the best option may 
 					be to leave the term untranslated, or to include the English term in parentheses. Don't focus too much on the 100% mark of translated strings, focus on providing 
 					a good translation, even if that means skipping some strings (or even skipping some message catalogs as a whole). Other users may be able to fill in any gaps in technical
 					terms.</para></listitem>
 			<listitem><para>At the time of this writing, &rkward;'s project hosting is about to change, and this also affect the translation workflow. Do read comments accompanying 
 					the .pot-files, on how translations should be handled. If in doubt, it is never wrong to send your work the rkward-devel mailing list, or to ask for up-to-date instructions,
 					there.</para></listitem>
 		</itemizedlist>
 	</sect1>
 </chapter>
 
 <chapter id="chapter_about_information">
 <title>Author, license and version information</title>
 <para>So you have written a set of plugins, and you are getting ready to <link linkend="external_plugins">share your work</link>. To make sure users will know what your work is all about, under what terms they can use and distribute it, and whom they should contact about issues or ideas, you should add some information <emphasis>about</emphasis> your plugins. This can be done using the <command>&lt;about&gt;</command> element. It can be used in either the &pluginmap; or in individual plugin .xml files (in both cases as a direct child of the document tag). When specified in the &pluginmap; it will apply to all plugins. If <command>&lt;about&gt;</command> is specified in both places, the <command>&lt;about&gt;</command> information in the plugin .xml file will override that in the &pluginmap; file. You can also add an <command>&lt;about&gt;</command> element to .rkh-pages, which are not connected to a plugin, if there is a need for that.</para>
 <para>Here's an example &pluginmap; file with only a few explanations, below. In cases of doubt, more information may be available from the reference.</para>
 <programlisting>
 &lt;document 
 	namespace="rkward"
 	id="SquaretheCircle_rkward"
 &gt;
 	&lt;about 
 		name="Square the Circle"
 		shortinfo="Squares the circle using Heisenberg compensation."
 		version="0.1-3"
 		releasedate="2011-09-19"
 		url="http://eternalwondermaths.example.org/23/stc.html"
 		license="GPL"
 		category="Geometry"
 	&gt;
 		&lt;author 
 			given="E.A."
 			family="Dölle"
 			email="doelle@eternalwondermaths.example.org"
 			role="aut"
 		 /&gt;
 		&lt;author 
 			given="A."
 			family="Assistant"
 			email="alterego@eternalwondermaths.example.org"
 			role="cre, ctb"
 		 /&gt;
 	&lt;/about&gt;
 	&lt;dependencies&gt;
 		...
 	&lt;/dependencies&gt;
 	&lt;components&gt;
 		...
 	&lt;/components&gt;
 	&lt;hierarchy&gt;
 		...
 	&lt;/hierarchy&gt;
 &lt;/document&gt;
 </programlisting>
 <para>Most of this should explain itself, so we’ll not discuss each and every tag element. But let’s look at some details that probably need some commentary for easier understanding. </para>
 <para>The <parameter>category</parameter> element in <command>&lt;about&gt;</command> can be defined rather freely, but should be meaningful, as it’s thought to be used to order plugins into groups. All other attributes in this opening tag are mandatory and must be filled with reasonable content. </para>
 <para>At least one <command>&lt;author&gt;</command> with a valid email address and the role <quote>aut</quote> (<quote>author</quote>) must also be given. In case your plugin causes problems or someone would like to share its gratitude with you, it should be easy to contact someone who’s involved. For further information on other valid roles, like <quote>ctb</quote> for code contributors or <quote>cre</quote> for package maintenance, please refer to the <ulink url="http://stat.ethz.ch/R-manual/R-patched/library/utils/html/person.html">R documentation on <function>person()</function></ulink>. </para>
 <note><para>Remember that you can use <command>&lt;include&gt;</command> and / or <command>&lt;insert&gt;</command> to repeat information across several .xml files (&eg; information on an author who was involved with several plugins). <link linkend="sect_similar_plugins">More information</link>.</para></note>
 <tip><para>You don't have to write this XML code by hand. If you use the function <function>rk.plugin.skeleton()</function> from the <link linkend="rkwarddev"><application>rkwarddev</application> package</link> and provide all necessary information via the <parameter>about</parameter> option, it will automatically create a &pluginmap; file with a working &lt;about&gt; section for you.</para></tip>
 </chapter>
 
 <chapter id="external_plugins">
 <title>Share your work with others</title>
 <sect1 id="sect_external_plugins"><title>External plugins</title>
 	<para>
 		As of version 0.5.5, &rkward; provides a comfortable way to install additional third party plugins which do not belong to the core package itself. We call these <quote>external plugins</quote>. They come in form of an &r; package and can be managed directly via the usual package management features of &r; and/or &rkward;.
 	</para>
 	<para>
 		This section of the documentation describes how external plugins are to be packaged, so that &rkward; can use them. The plugin creation itself is of course identical to the previous sections. That is, you should probably first write a working plugin, and then check back here to learn how to distribute it.
 	</para>
 	<para>
 		Since external plugins are a relatively young feature, details of this might probably change in future releases. You’re welcome to contribute your ideas to improve the process.
 	</para>
 	<tip>
 		<para>
 			These docs explain the details of external plugins so you can learn how they work. In addition to that, also have a look at the <link linkend="rkwarddev"><application>rkwarddev</application> package</link>, which was designed to automate a lot of the writing process.
 		</para>
 	</tip>
 </sect1>
 <sect1 id="why_external_plugins">
 <title>Why external plugins?</title>
 	<para>
 		The number of packages to extend the functionality of &r; is immense already, and climbing. On one hand, we want to encourage you to write plugins for even the most specialised tasks you need solved. On the other hand, the average user should not get lost in huge menu trees full of unknown statistical terms. Therefore it seemed reasonable to keep the plugin handling in &rkward; quite modular as well. The &rkward; team maintains its own public package repository at <ulink url="http://files.kde.org/rkward/R">http://files.kde.org/rkward/R</ulink>, designated to host your external plugins.
 	</para>
 	<para>
 		As a rule of thumb, plugins that seem to serve a widely used purpose (&eg; t-Tests) should become part of the core package, while those who serve a rather limited group of people with special interests should be provided as an optional package. For you as a plugin author it’s best practice to just start with an external plugin.
 	</para>
 </sect1>
   
 <sect1 id="structure_of_a_plugin_package">
 <title>Structure of a plugin package</title>
 	<para>For external plugins to install and work properly, they must follow some structural guidelines regarding their file hierarchy. </para>
     
 	<sect2 id="file_hierarchy"><title>File hierarchy</title>
 		<para>
 			Lets have a look at the prototypic file hierarchy of an elaborate plugin archive. You don’t have to include all of these directories and/or files for a plugin to work (read on to learn what’s absolutely necessary), consider this a <quote>best practice</quote> example:
 		</para>
 		<programlisting>
 	plugin_name/
 		inst/
 			rkward/
 				plugins/
 					plugin_name.xml
 					plugin_name.js
 					plugin_name.rkh
 					...
 				po/
 					ll/
 						LC_MESSAGES/
 							rkward__plugin_name_rkward.mo
 					rkward__plugin_name_rkward.ll.po
 					rkward__plugin_name_rkward.pot
 				tests/
 					testsuite_name/
 						RKTestStandards.sometest_name.rkcommands.R
 						RKTestStandards.sometest_name.rkout
 						...
 					testsuite.R
 				plugin_name.pluginmap
 				...
 	ChangeLog
 	README
 	AUTHORS
 	LICENSE
 	DESCRIPTION
 		</programlisting>
 		<note>
 			<para>
 				In this example, all occasions of <token>plugin_name</token>, <token>testsuite_name</token> and <token>sometest_name</token> are to be replaced with their correct names, accordingly. Also, <token>ll</token> is a placeholder for a language abbreviation (&eg;, <quote>de</quote>, <quote>en</quote> or <quote>es</quote>).
 			</para>
 		</note>
 		<tip>
 			<para>
 				You don't have to create this file hierarchy by hand. If you use the function <function>rk.plugin.skeleton()</function> from the <link linkend="rkwarddev"><application>rkwarddev</application> package</link>, it will automatically create all necessary files and directories for you, except the <filename>po</filename> directory which is created and managed by the <link linkend="i18n_workflow">translation script</link>.
 			</para>
 		</tip>
 		<sect3 id="basic_plugin_components">
 		<title>Basic plugin components</title>
 			<para>
 				It is mandatory to include at least three files: a <link linkend="pluginmap">&pluginmap;</link>, a plugin <link linkend="mainxml">.xml</link> description and a plugin <link linkend="jstemplate">.js</link> file. That is, even the "plugins" directory is optional. It might just help to give your files some order, especially if you include more that one plugin/dialog in the archive, which is of course no problem. You can have as many directories for the actual plugin files as you see fit, they just have to resemble the <link linkend="pluginmap">&pluginmap;</link>, respectively. It is also possible to even include several &pluginmap; files, if it fits your needs, but you should include them all in <quote>plugin_name.pluginmap</quote> then.
 			</para>
 			<para>
 				Each &r; package must have a valid <filename>DESCRIPTION</filename> file, which is also crucial for &rkward; recognizing it as a plugin provider. Most of the information it carries is also needed in the plugin <link linkend="chapter_about_information">Meta-information</link> and possibly <link linkend="chapter_dependencies">dependencies</link>, but in a different format (the &r; documentation explains <ulink url="http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file">the <filename>DESCRIPTION</filename> file in detail</ulink>).
 			</para>
 			<para>
 				In addition to the general contents of a <filename>DESCRIPTION</filename> file, make sure to also include the line <quote>Enhances: rkward</quote>. This will cause &rkward; to automatically scan the package for plugins if it is installed. An example <filename>DESCRIPTION</filename> file looks like this:
 			</para>
 			<programlisting>
 	Package: SquaretheCircle
 	Type: Package
 	Title: Square the circle
 	Version: 0.1-3
 	Date: 2011-09-19
 	Author: E.A. Dölle &lt;doelle@eternalwondermaths.example.org&gt;
 	Maintainer: A. Assistant &lt;alterego@eternalwondermaths.example.org&gt;
 	Enhances: rkward
 	Description: Squares the circle using Heisenberg compensation.
 	License: GPL
 	LazyLoad: yes
 	URL: http://eternalwondermaths.example.org/23/stc.html
 	Authors@R: c(person(given="E.A.", family="Dölle", role="aut",
 			email="doelle@eternalwondermaths.example.org"),
 			person(given="A.", family="Assistant", role=c("cre",
 			"ctb"), email="alterego@eternalwondermaths.example.org"))
 			</programlisting>
 			<tip>
 				<para>
 					You don't have to write this file by hand. If you use the function <function>rk.plugin.skeleton()</function> from the <link linkend="rkwarddev"><application>rkwarddev</application> package</link> and provide all necessary information via the <quote>about</quote> option, it will automatically create a working <filename>DESCRIPTION</filename> file for you.
 				</para>
 			</tip>
 		</sect3>
 		<sect3 id="additional_information">
 		<title>Additional information (optional)</title>
 			<para>
 				<filename>ChangeLog</filename>, <filename>README</filename>, <filename>AUTHORS</filename>, <filename>LICENSE</filename> should be self-explaining and are entirely optional. Actually, they won’t be interpreted by &rkward;, so they are rather meant to carry additional information that might be relevant &eg; for distributors. Most of their relevant content (author credits, licence terms &etc;) will be included in the actual plugin files anyway, though (see the <link linkend="chapter_about_information">section on meta-information</link>). Note that all of these files could also be placed somewhere in the "inst" directory, if you want them not only to be present in the source archive but the installed package as well.
 			</para>
 		</sect3>
 		<sect3 id="automated_plugin_testing">
 		<title>Automated plugin testing (optional)</title>
 			<para>
 				Another optional directory is "tests", which is meant to provide files needed for <ulink url="http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Automated_Plugin_Testing">automated plugin testing</ulink>. These tests are helpful to quickly check if your plugins still work with new versions of &r; or &rkward;. If you want to include tests, you should really restrain yourself to the naming scheme and hierarchy shown here. That is, tests should reside in a directory called <filename>tests</filename>, which includes a file <filename>testsuite.R</filename> and a folder with tests standards named after the appropriate test suite. You can, however, provide more than one test suite; in that case, if you don’t want to append them all in the one <filename>testsuite.R</filename> file, you can split them in &eg; one file for each test suite and create one <filename>testsuite.R</filename> with <function>source()</function> calls for each suite file. In either case, create separate subdirectories with test 
 standards for each defined suite.
 			</para>
 			<para>
 				The benefits of upholding to this structure is that plugin tests can be run simply by calling <function>rktests.makplugintests()</function> from the <ulink url="rkward://rhelp/rkwardtests">rkwardtests</ulink> package without additional arguments. Have a look at the online documentation on <ulink url="http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Automated_Plugin_Testing">Automated Plugin Testing</ulink> for further details.
 			</para>
 		</sect3>
 	</sect2>
 </sect1>
   
 	<sect1 id="building_the_plugin_package">
 		<title>Building the plugin package</title>
 		<para>As explained earlier, external &rkward; plugins are in effect &r; packages, and therefore the packaging process is identical. In contrast to "real" &r; packages, a pure plugin package doesn't carry any further &r; code (although you can of course add &rkward; plugins to usual &r; packages as well, using the same methods explained here). This should make it even easier to create a functioning package, as long as you have a valid <filename>DESCRIPTION</filename> file and adhere to the file hierarchy explained in <link linkend="structure_of_a_plugin_package">previous sections</link>.</para>
 		<para>The easiest way to actually build and test your plugin is to use the <application>R</application> command on the command line, for example:</para>
 		<para><userinput>
 			<command>R</command> <option>CMD build</option> <parameter><filename>SquaretheCircle</filename></parameter>
 		</userinput></para>
 		<para><userinput>
 			<command>R</command> <option>CMD INSTALL</option> <parameter><filename>SquaretheCircle_0.1-3.tar.gz</filename></parameter>
 		</userinput></para>
 		<tip><para>You don't have to build the package like this on the command line. If you use the function <function>rk.build.package()</function> from the <link linkend="rkwarddev"><application>rkwarddev</application> package</link>, it will build and/or check your plugin package for you.</para></tip>
 	</sect1>
 </chapter>
 
 <chapter id="rkwarddev">
 	<title>Plugin development with the <application>rkwarddev</application> package</title>
 	<sect1 id="rkdev_overview"><title>Overview</title>
 		<para>Writing external plugins involves writing files in three languages (XML, JavaScript and R) and the creation of a standardized hierarchy of directories. To make this a lot easier for willing plugin developers, we're providing the <application>rkwarddev</application> package. It provides a number of simple &r; functions to create the XML code for all dialog elements like tabbooks, checkboxes, dropdownlists or filebrowsers, as well as functions to create JavaScript code and &rkward; help files to start with. The function <function>rk.plugin.skeleton()</function> creates the expected directory tree and all necessary files where they are supposed to be.</para>
 		<para>This package is not installed by default, but has to be installed manually from <ulink url="http://files.kde.org/rkward/R/">&rkward;'s own repository</ulink>. You can either do that by using the GUI interface (<menuchoice><guimenu>Settings</guimenu><guimenuitem>Configure packages</guimenuitem></menuchoice>), or from any running &r; session:</para>
 		<programlisting>
 		install.packages("rkwarddev", repos="http://files.kde.org/rkward/R")
 		library(rkwarddev)
 		</programlisting>
 		<para><application>rkwarddev</application> depends on another small package called <quote>XiMpLe</quote>, which is a very simple XML parser and generator and also present in the same repository.</para>
 		<para>The full <ulink url="http://http://files.kde.org/rkward/R/pckg/rkwarddev/rkwarddev.pdf">documentation in PDF format</ulink> can also be found there. A more detailed introduction to working with the package can be found in the <ulink url="http://files.kde.org/rkward/R/pckg/rkwarddev/rkwarddev_vignette.pdf">rkwarddev vignette</ulink>.</para>
 	</sect1>
 
 	<sect1 id="rkdev_example"><title>Practical example</title>
 		<para>To get you an idea how <quote>scripting a plugin</quote> looks like, compared to the direct approach you have seen in the previous chapters, we'll create the full t-test plugin once again -- this time only with the &r; functions of the <application>rkwarddev</application> package.</para>
 
 		<tip><para>The package will add a new GUI dialog to &rkward; under <menuchoice><guimenu>File</guimenu><guimenuitem>Export</guimenuitem><guimenuitem>Create &rkward; plugin skeleton</guimenuitem></menuchoice>. Like the name suggests, you can create plugin skeletons for further editing with it. This dialog itself was in turn generated by an <application>rkwarddev</application> script which you can find in the <quote>demo</quote> directory of the installed package and package sources, as an additional example. You can also run it by calling <function>demo("skeleton_dialog")</function></para></tip>
 
 		<sect2 id="rkdev_gui"><title>GUI description</title>
 		<para>You will immediately notice that the workflow is considerably different: Contrary to writing the XML code directly, you do not begin with the <command>&lt;document&gt;</command> definition, but directly with the plugin elements you'd like to have in the dialog. You can assign each interface element -- be it check boxes, dropdown menus, variable slots or anything else -- to individual &r; objects, and then combine these objects to the actual GUI. The package has functions for <link linkend="interfaceelements">each XML tag</link> that can be used to define the plugin GUI, and most of them even have the same name, only with the prefix <function>rk.XML.*</function>. For example, defining a <command>&lt;varselector&gt;</command> and two <command>&lt;varslot&gt;</command> elements for the <replaceable>"x"</replaceable> and <replaceable>"y"</replaceable> variable of the t-test example can be done by:</para>
 		<programlisting>
 variables &lt;- rk.XML.varselector(id.name="vars")
 var.x &lt;- rk.XML.varslot("compare", source=variables, types="number", required=TRUE, id.name="x")
 var.y &lt;- rk.XML.varslot("against", source=variables, types="number", required=TRUE, id.name="y")
 		</programlisting>
 		<para>The most interesting detail is probably <parameter>source=</parameter><replaceable>variables</replaceable>: A prominent feature of the package is that all functions can generate automatic IDs, so you don't have to bother with either thinking of <parameter>id</parameter> values or remembering them to refer to a specific plugin element. You can simply give the &r; objects as reference, as all functions who need an ID from some other element can also read it from these objects. <function>rk.XML.varselector()</function> is a little special, as it usually has no specific content to make an ID from (it can, but only if you specify a label), so we have to set an ID name. But <function>rk.XML.varslot()</function> wouldn't need the <parameter>id.name</parameter> arguments here, so this would suffice:</para>
 		<programlisting>
 variables &lt;- rk.XML.varselector(id.name="vars")
 var.x &lt;- rk.XML.varslot("compare", source=variables, types="number", required=TRUE)
 var.y &lt;- rk.XML.varslot("against", source=variables, types="number", required=TRUE)
 		</programlisting>
 		<para>In order to recreate the example code to the point, you'd have to set all ID values manually. But since the package shall make our lives easier, from now on we will no longer care about that.</para>
 		<tip>
 			<para>
 				<application>rkwarddev</application> is capable of a lot of automation to help you build your plugins. However, it might be preferable to not use it to its full extend. If your goal is to produce code that is not only working but can also be easily read and compared to your generator script by a human being, you should consider to always set useful IDs with <parameter>id.name</parameter>. Naming your R objects identical to these IDs will also help in getting script code that is easy to understand.
 			</para>
 		</tip>
 		<para>If you want to see how the XML code of the defined element looks like if you exported it to a file, you can just call the object by its name. So, if you now called <quote>var.x</quote> in your &r; session, you should see something like this:</para>
 		<programlisting>
 &lt;varslot id="vrsl_compare" label="compare" source="vars" types="number" required="true" /&gt;
 		</programlisting>
 		<para>Some tags are only useful in the context of others. Therefore, for instance, you won't find a function for the <command>&lt;option&gt;</command> tag. Instead, both radio buttons and dropdown lists are defined including their options as a named list, where the names represent the labels to be shown in the dialog, and their value is a named vector which can have two entries, <parameter>val</parameter> for the value of an option and the boolean <parameter>chk</parameter> to specify if this option is checked by default.</para>
 		<programlisting>
 test.hypothesis &lt;- rk.XML.radio("using test hypothesis",
 	options=list(
 		"Two-sided"=c(val="two.sided"),
 		"First is greater"=c(val="greater"),
 		"Second is greater"=c(val="less")
 	)
 )
 		</programlisting>
 		<para>The result looks like this:</para>
 		<programlisting>
 &lt;radio id="rad_usngtsth" label="using test hypothesis"&gt;
 	&lt;option label="Two-sided" value="two.sided" /&gt;
 	&lt;option label="First is greater" value="greater" /&gt;
 	&lt;option label="Second is greater" value="less" /&gt;
 &lt;/radio&gt;
 		</programlisting>
 		<para>All that's missing from the elements of the <quote>Basic settings</quote> tab is the check box for paired samples, and the structuring of all of these elements in rows and columns:</para>
 		<programlisting>
 check.paired &lt;- rk.XML.cbox("Paired sample", value="1", un.value="0")
 basic.settings &lt;- rk.XML.row(variables, rk.XML.col(var.x, var.y, test.hypothesis, check.paired))
 		</programlisting>
 		<para><function>rk.XML.cbox()</function> is a rare exception where the function name does not contain the full tag name, to save some typing for this often used element. This is what <function>basic.settings</function> now contains:</para>
 		<programlisting>
 &lt;row id="row_vTFSPP10TF"&gt;
 	&lt;varselector id="vars" /&gt;
 	&lt;column id="clm_vrsTFSPP10"&gt;
 		&lt;varslot id="vrsl_compare" label="compare" source="vars" types="number" required="true" /&gt;
 		&lt;varslot id="vrsl_against" label="against" i18n_context="compare against" source="vars" types="number" required="true" /&gt;
 		&lt;radio id="rad_usngtsth" label="using test hypothesis"&gt;
 			&lt;option label="Two-sided" value="two.sided" /&gt;
 			&lt;option label="First is greater" value="greater" /&gt;
 			&lt;option label="Second is greater" value="less" /&gt;
 		&lt;/radio&gt;
 		&lt;checkbox id="chc_Pardsmpl" label="Paired sample" value="1" value_unchecked="0" /&gt;
 	&lt;/column&gt;
 &lt;/row&gt;
 		</programlisting>
 		<para>In a similar manner, the next lines will create &r; objects for the elements of the <quote>Options</quote> tab, introducing functions for spinboxes, frames and stretch:</para>
 		<programlisting>
 check.eqvar &lt;- rk.XML.cbox("assume equal variances", value="1", un.value="0")
 conf.level &lt;- rk.XML.spinbox("confidence level", min=0, max=1, initial=0.95)
 check.conf &lt;- rk.XML.cbox("print confidence interval", val="1", chk=TRUE)
 conf.frame &lt;- rk.XML.frame(conf.level, check.conf, rk.XML.stretch(), label="Confidence Interval")
 		</programlisting>
 		<para>Now all we need to do is to put the objects together in a tabbook, and place that in a dialog section:</para>
 		<programlisting>
 full.dialog &lt;- rk.XML.dialog(
 	label="Two Variable t-Test",
 	rk.XML.tabbook(tabs=list("Basic settings"=basic.settings, "Options"=list(check.eqvar, conf.frame)))
 )
 		</programlisting>
 		<para>We can also create the wizard section with its two pages using the same objects, so their IDs will be extracted for the <command>&lt;copy&gt;</command> tags:</para>
 		<programlisting>
 full.wizard &lt;- rk.XML.wizard(
 		label="Two Variable t-Test",
 		rk.XML.page(
 			rk.XML.text("As a first step, select the two variables you want to compare against
 				each other. And specify, which one you theorize to be greater. Select two-sided,
 				if your theory does not tell you, which variable is greater."),
 			rk.XML.copy(basic.settings)),
 		rk.XML.page(
 			rk.XML.text("Below are some advanced options. It's generally safe not to assume the
 				variables have equal variances. An appropriate correction will be applied then.
 				Choosing \"assume equal variances\" may increase test-strength, however."),
 			rk.XML.copy(check.eqvar),
 			rk.XML.text("Sometimes it's helpful to get an estimate of the confidence interval of
 				the difference in means. Below you can specify whether one should be shown, and
 				which confidence-level should be applied (95% corresponds to a 5% level of
 				significance)."),
 			rk.XML.copy(conf.frame)))
 		</programlisting>
 		<para>That's it for the GUI. The global document will be combined in the end by <function>rk.plugin.skeleton()</function>.</para>
 		</sect2>
 
 		<sect2 id="rkdev_jscode"><title>JavaScript code</title>
 			<para>Until now, using the <application>rkwarddev</application> package might not seem to have helped so much. This is going to change right now.</para>
 			<para>First of all, just like we didn't have to care about IDs for elements when defining the GUI layout, we don't have to care about JavaScript variable names in the next step. If you want more control, you can write plain JavaScript code and have it pasted to the generated file. But it's probably much more efficient to do it the <application>rkwarddev</application> way.</para>
 			<para>Most notably you don't have to define any variable yourself, as <function>rk.plugin.skeleton()</function> can scan your XML code and automatically define all variables you will probably need -- for instance, you wouldn't bother to include a check box if you don't use its value or state afterwards. So we can start writing the actual &r; code generating JS immediately.</para>
 			<tip><para>The function <function>rk.JS.scan()</function> can also scan existing XML files for variables.</para></tip>
 			<para>The package has some functions for JS code constructs that are commonly used in &rkward; plugins, like the <function>echo()</function> function or <function>if() {...} else {...}</function> conditions. There are some differences between JS and R, &eg;, for <function>paste()</function> in &r; you use the comma to concatenate character strings, whereas for <function>echo()</function> in JS you use <quote>+</quote>, and lines must end with a semicolon. By using the &r; functions, you can almost forget about these differences and keep writing &r; code.</para>
 			<para>These functions can take different classes of input objects: Either plain text, &r; objects with XML code like above, or in turn results of some other JS functions of the package. In the end, you will always call <function>rk.paste.JS()</function>, which behaves similar to <function>paste()</function>, but depending on the input objects it will replace them with their XML ID, JavaScript variable name or even complete JavaScript code blocks.</para>
 			<para>For the t-test example, we need two JS objects: One to calculate the results, and one to print them in the <function>printout()</function> function:</para>
 		<programlisting>
 JS.calc &lt;- rk.paste.JS(
 	echo("res &lt;- t.test (x=", var.x, ", y=", var.y, ", hypothesis=\"", test.hypothesis, "\""),
 	js(
 		if(check.paired){
 			echo(", paired=TRUE")
 		},
 		if(!check.paired &amp;&amp; check.eqvar){
 			echo(", var.equal=TRUE")
 		},
 		if(conf.level != "0.95"){
 			echo(", conf.level=", conf.level)
 		},
 		linebreaks=TRUE
 	),
 	echo(")\n"),
 	level=2
 )
 
 JS.print &lt;- rk.paste.JS(echo("rk.print (res)\n"), level=2)
 		</programlisting>
 		<para>As you can see, <application>rkwarddev</application> also provides an &r; implementation of the <function>echo()</function> function. It returns exactly one character string with a valid JS version of itself. You might also notice that all of the &r; objects here are the ones we created earlier. They will automatically be replaced with their variable names, so this should be quite intuitive. Whenever you need just this replacement, the function <function>id()</function> can be used, which also will return exactly one character string from all the objects it was given (you could say it behaves like <function>paste()</function> with a very specific object substitution).</para>
     <para>The <function>js()</function> function is a wrapper that allows you to use &r;'s <command>if(){...} else {...}</command> conditions like you are used to. They will be translated directly into JS code. It also preserves some operators like <command>&lt;</command>, <command>&gt;=</command> or <command>||</command>, so you can logically compare your &r; objects without the need for quoting most of the time. Let's have a look at the resulting <quote>JS.calc</quote> object, which now contains a character string with this content:</para>
 		<programlisting>
 	echo("res &lt;- t.test (x=" + vrslCompare + ", y=" + vrslAgainst + ", hypothesis=\"" + radUsngtsth + "\"");
 	if(chcPardsmpl) {
 		echo(", paired=TRUE");
 	} else {}
 	if(!chcPardsmpl &amp;&amp; chcAssmqlvr) {
 		echo(", var.equal=TRUE");
 	} else {}
 	if(spnCnfdnclv != "0.95") {
 		echo(", conf.level=" + spnCnfdnclv);
 	} else {}
 	echo(")\n");
 		</programlisting>
     <note>
       <para>
         Alternatively for <function>if()</function> conditions nested in <function>js()</function>, you can use the <function>ite()</function> function, which behaves similar to &r;'s <function>ifelse()</function>. However, conditional statements constructed using <function>ite()</function> are usually harder to read and should be replaced by <function>js()</function> whenever possible.
       </para>
     </note>
 		</sect2>
 
 		<sect2 id="rkdev_pluginmap"><title>Plugin map</title>
 		<para>This section is very short: We don't need to write a &pluginmap; at all, as it can be generated automatically by <function>rk.plugin.skeleton()</function>. The menu hierarchy can be specified via the <parameter>pluginmap</parameter> option:</para>
 			<programlisting>
 	[...]
 	pluginmap=list(
 		name="Two Variable t-Test",
 		hierarchy=list("analysis", "means", "t-Test"))
 	[...]
 			</programlisting>
 		</sect2>
 
 		<sect2 id="rkdev_rkh"><title>Help page</title>
 			<para>This section is very short as well: <function>rk.plugin.skeleton()</function> cannot write a whole help page from the information it has. But it can scan the XML document also for elements which probably deserve a help page entry, and automatically create a help page template for our plugin. All we have to do afterwards is to write some lines for each listed section.</para>
 			<tip><para>The function <function>rk.rkh.scan()</function> can also scan existing XML files to create a help file skeleton.</para></tip>
 		</sect2>
 
 		<sect2 id="rkdev_plugin_generator"><title>Generate the plugin files</title>
 			<para>Now comes the final step, in which we'll hand over all generated objects to <function>rk.plugin.skeleton()</function>:</para>
 			<programlisting>
 plugin.dir &lt;- rk.plugin.skeleton("t-Test",
 	xml=list(
 		dialog=full.dialog,
 		wizard=full.wizard),
 	js=list(
 		results.header="Two Variable t-Test",
 		calculate=JS.calc,
 		printout=JS.print),
 	pluginmap=list(
 		name="Two Variable t-Test",
 		hierarchy=list("analysis", "means", "t-Test")),
 	load=TRUE,
 	edit=TRUE,
 	show=TRUE)
 			</programlisting>
 			<para>The files will be created in a temporal directory by default. The last three options are not necessary, but very handy: <parameter>load=</parameter><replaceable>TRUE</replaceable> will automatically add the new plugin to &rkward;s configuration (since it's in a temp dir and hence will cease to exist when &rkward; is closed, it will automatically be removed again by &rkward; during its next start), <parameter>edit=</parameter><replaceable>TRUE</replaceable> will open all created files for editing in &rkward; editor tabs, and <parameter>show=</parameter><replaceable>TRUE</replaceable> will attempt to directly launch the plugin, so you can examine what it looks like without a klick. You might consider adding <parameter>overwrite=</parameter><replaceable>TRUE</replaceable> if you're about to run your script repeatedly (&eg; after changes to the code), as by default no files will be overwritten.</para>
 			<para>The result object <quote>plugin.dir</quote> contains the path to the directory in which the plugin was created. This can be useful in combination with the function <function>rk.build.package()</function>, to build an actual &r; package to share your plugin with others -- &eg; by sending it to the &rkward; development team to be added to our plugin repository.</para>
 		</sect2>
 		<sect2 id="rkdev_ttest_script"><title>The full script</title>
 		<para>To recapitulate all of the above, here's the full script to create the working t-test example. Adding to the already explained code, it also loads the package if needed, and it uses the <function>local()</function> environment, so all the created objects will not end up in your current workspace (except for <quote>plugin.dir</quote>):</para>
 		<programlisting>
 require(rkwarddev)
 
 local({
 	variables &lt;- rk.XML.varselector(id.name="vars")
 	var.x &lt;- rk.XML.varslot("compare", source=variables, types="number", required=TRUE)
 	var.y &lt;- rk.XML.varslot("against", source=variables, types="number", required=TRUE)
 	test.hypothesis &lt;- rk.XML.radio("using test hypothesis",
 		options=list(
 			"Two-sided"=c(val="two.sided"),
 			"First is greater"=c(val="greater"),
 			"Second is greater"=c(val="less")
 		)
 	)
 	check.paired &lt;- rk.XML.cbox("Paired sample", value="1", un.value="0")
 	basic.settings &lt;- rk.XML.row(variables, rk.XML.col(var.x, var.y, test.hypothesis, check.paired))
 
 	check.eqvar &lt;- rk.XML.cbox("assume equal variances", value="1", un.value="0")
 	conf.level &lt;- rk.XML.spinbox("confidence level", min=0, max=1, initial=0.95)
 	check.conf &lt;- rk.XML.cbox("print confidence interval", val="1", chk=TRUE)
 	conf.frame &lt;- rk.XML.frame(conf.level, check.conf, rk.XML.stretch(), label="Confidence Interval")
 
 	full.dialog &lt;- rk.XML.dialog(
 		label="Two Variable t-Test",
 		rk.XML.tabbook(tabs=list("Basic settings"=basic.settings, "Options"=list(check.eqvar, conf.frame)))
 	)
 
 	full.wizard &lt;- rk.XML.wizard(
 			label="Two Variable t-Test",
 			rk.XML.page(
 				rk.XML.text("As a first step, select the two variables you want to compare against
 					each other. And specify, which one you theorize to be greater. Select two-sided,
 					if your theory does not tell you, which variable is greater."),
 				rk.XML.copy(basic.settings)),
 			rk.XML.page(
 				rk.XML.text("Below are some advanced options. It's generally safe not to assume the
 					variables have equal variances. An appropriate correction will be applied then.
 					Choosing \"assume equal variances\" may increase test-strength, however."),
 				rk.XML.copy(check.eqvar),
 				rk.XML.text("Sometimes it's helpful to get an estimate of the confidence interval of
 					the difference in means. Below you can specify whether one should be shown, and
 					which confidence-level should be applied (95% corresponds to a 5% level of
 					significance)."),
 				rk.XML.copy(conf.frame)))
 
 	JS.calc &lt;- rk.paste.JS(
 		echo("res &lt;- t.test (x=", var.x, ", y=", var.y, ", hypothesis=\"", test.hypothesis, "\""),
 		js(
 			if(check.paired){
 			echo(", paired=TRUE")
 			},
 			if(!check.paired &amp;&amp; check.eqvar){
 			echo(", var.equal=TRUE")
 			},
 			if(conf.level != "0.95"){
 			echo(", conf.level=", conf.level)
 			},
 			linebreaks=TRUE
 		),
 		echo(")\n"), level=2)
 
 	JS.print &lt;- rk.paste.JS(echo("rk.print (res)\n"), level=2)
 
 	plugin.dir &lt;&lt;- rk.plugin.skeleton("t-Test",
 		xml=list(
 			dialog=full.dialog,
 			wizard=full.wizard),
 		js=list(
 			results.header="Two Variable t-Test",
 			calculate=JS.calc,
 			printout=JS.print),
 		pluginmap=list(
 			name="Two Variable t-Test",
 			hierarchy=list("analysis", "means", "t-Test")),
 		load=TRUE,
 		edit=TRUE,
 		show=TRUE,
 		overwrite=TRUE)
 })
 		</programlisting>
 		</sect2>
 
   </sect1>
   <sect1 id="rkwarddev_rkh"><title>Adding help pages</title>
     <para>
       If you want to write a help page for your plugin, the most straight forward way to do so is to add the particular instructions directly to the definitions of the XML elements they belong to:
     </para>
     <programlisting>
 variables &lt;- rk.XML.varselector(
   id.name="vars",
   help="Select the data object you would like to analyse.",
   component="Data"
 )
     </programlisting>
     <para>
       The text given to the <parameter>help</parameter> parameter can then be fetched by <function>rk.rkh.scan()</function> and written to the help page of this plugin component. For this to work technically, however, <function>rk.rkh.scan()</function> must know which &r; objects belong to one plugin component. This is why you must also provide the <parameter>component</parameter> parameter and make sure it is identical for all objects belonging together.
     </para>
     <para>
       Since you will usually combine many objects into one dialog and might also like to be able to re-use objects like the <command>&lt;varslot&gt;</command> in multiple components of your plugins, it is possible to globally define a component with the <function>rk.set.comp()</function>. If set, it is assumed that all the following objects used in your script belong to that particular component, until <function>rk.set.comp()</function> is being called again with a different component name. You can then omit the <parameter>component</parameter> parameter:
     </para>
     <programlisting>
 rk.set.comp("Data")
 variables &lt;- rk.XML.varselector(
   id.name="vars",
   help="Select the data object you would like to analyse."
 )
     </programlisting>
     <para>
       To add global sections like <command>&lt;summary&gt;</command> or <command>&lt;usage&gt;</command> to the help page, you use functions like <function>rk.rkh.summary()</function> or <function>rk.rkh.usage()</function> accordingly. Their results are then used to set the list elements like <parameter>summary</parameter> or <parameter>usage</parameter> in the <parameter>rkh</parameter> parameter of <function>rk.plugin.component()</function>/<function>rk.plugin.skeleton()</function>.
     </para>
 	</sect1>
   <sect1 id="rkwarddev_i18n"><title>Translating plugins</title>
     <para>
       The <application>rkwarddev</application> package is capable of producing external plugins with full i18n support. For instance, all relevant functions generating XML objects offer an optional parameter to specify <replaceable>i18n_context</replaceable> or <replaceable>noi18n_label</replaceable>:
     </para>
     <programlisting>
 varComment &lt;- rk.XML.varselector(id.name="vars", i18n=list(comment="Main variable selector"))
 varContext &lt;- rk.XML.varselector(id.name="vars", i18n=list(context="Main variable selector"))
 cboxNoi18n &lt;- rk.XML.cbox(label="Power", id.name="power", i18n=FALSE)
     </programlisting>
     <para>The above examples produce output like this:</para>
     <programlisting>
 # varComment
 &lt;!-- i18n: Main variable selector --&gt;
   &lt;varselector id="vars" /&gt;
 
 # varContext
 &lt;varselector id="vars" i18n_context="Main variable selector" /&gt;
 
 # cboxNoi18n
 &lt;checkbox id="power" noi18n_label="Power" value="true" /&gt;
     </programlisting>
     <para>
       There's also support for translatable JS code. In fact, the package tries add <function>i18n()</function> calls by default in places where this is usually helpful. The <function>rk.JS.header()</function> function is a good example:
     </para>
     <programlisting>
 jsHeader &lt;- rk.JS.header("Test results")
     </programlisting>
     <para>This produces the following JS code:</para>
     <programlisting>
 new Header(i18n("Test results")).print();
     </programlisting>
     <para>But you can also manually mark strings in your JS code as translatable, by using the <function>i18n()</function> function just like you would if you wrote the JS file directly.</para>
   </sect1>
 </chapter>
 
 <appendix id="reference">
 <title>Reference</title>
 
 <sect1 id="propertytypes"><title>Types of properties/Modifiers</title>
 <para>
 	At some places in this introduction we've talked about <quote>properties</quote> of GUI elements or otherwise. In fact there are several different types of properties. Usually you do not need to worry about this, as you can use common sense to connect any property to any other property. However, internally, there are different types of properties. What this matters for, is when fetching some special values in the JS-template. In getString ("id")/getBoolean ("id")/getList ("id") statements you can also specify some so called <quote>modifiers</quote> like this: <function>getString ("id.modifier")</function>. This modifier will affect, in which way the value is printed. Read on for the list of properties, and the modifiers they each make available:
 </para>
 <variablelist>
 <varlistentry>
 <term>String properties</term>
 <listitem><para>The most simple type of property, used to simply hold a piece of text. Modifiers:
 	<variablelist>
 	<varlistentry>
 	<term>No modifier ("")</term>
 	<listitem><para>The string as defined / set.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>quoted</term>
 	<listitem><para>The string in quoted form (suitable for passing to R as character).</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>Boolean properties</term>
 <listitem><para>Properties that can either be on or off, true or false. For instance the properties created by &lt;convert&gt;-tags, also the property accompanying a &lt;checkbox&gt; (see below). The following values will be returned according to the given modifier:
 	<variablelist>
 	<varlistentry>
 	<term>No modifier ("")</term>
 	<listitem><para>By default the property will return 1 if it is true, and 0 otherwise. The recommended way to fetch boolean values is using <function>getBoolean()</function>. Note that for <function>getString()</function>, the string "0" will be returned when the property is false. This string would evaluate to true, not to false in JS.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"labeled"</term>
 	<listitem><para>Returns the string "true" when true, "false", when false, or whichever custom strings have been specified (typically in a &lt;checkbox&gt;).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"true"</term>
 	<listitem><para>Return the string as if the property was true, even if it is false</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"false"</term>
 	<listitem><para>Return the string as if the property was false, even if it is true</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"not"</term>
 	<listitem><para>This actually returns another Boolean property, which is the reverse of the current (&ie; false if true, true if false)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"numeric"</term>
 	<listitem><para>Obsolete, provided for backwards compatibility. Same as no modifier "". Return "1" if the property is true, or "0" if it is false.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>Integer properties</term>
 <listitem><para>A property designed to hold an integer value (but of course it still returns a numeric character string to the JS-template). It does not accept any modifiers. Used in &lt;spinbox&gt;es (see below)</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>Real number properties</term>
 <listitem><para>A property designed to hold a real number value (but of course it still returns a numeric character string to the JS-template). Used in &lt;spinbox&gt;es (see below)
 	<variablelist>
 	<varlistentry>
 	<term>No modifier ("")</term>
 	<listitem><para>For <function>getValue() / getString()</function>, this returns the same as "formatted". In future versions, it will be possible to obtain a numeric represenation, instead.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"formatted"</term>
 	<listitem><para>Returns the formatted number (as a string).</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>RObject properties</term>
 <listitem><para>A property designed a selection of one or more &r; objects. Used most prominently in varselectors and varslots. The following values will be returned according to the given modifier:
 	<variablelist>
 	<varlistentry>
 	<term>No modifier ("")</term>
 	<listitem><para>By default the property will the full name of the selected object. If more than one object is selected, the object names will be separated by line breaks ("\n").</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"shortname"</term>
 	<listitem><para>Like above, but returns only short name(s) for the object(s). For instance an object inside a list would only be given the name it has inside the list, without the name of the list.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"label"</term>
 	<listitem><para>Like above, but returns the &rkward; label(s) of the object(s) (if no label available, this is the same as shortname)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>String list properties</term>
 <listitem><para>This property holds a list of strings.
 	<variablelist>
 	<varlistentry>
 	<term>No modifier ("")</term>
 	<listitem><para>For <function>getValue()/getString()</function>, this returns all strings separated by "\n". Any "\n" characters in each item are escaped as literal "\n". However, the recommended usage is to fetch the value with <function>getList()</function>, instead, which will return an array of strings.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"joined"</term>
 	<listitem><para>Returns the list as a single string, with items joined by "\n". In contrast to no modifier (""), the individual strings are _not_ escaped.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>Code properties</term>
 <listitem><para>A property held by plugins that generated code. This is important for embedding plugins, in order to embed the code generated by the embedded plugin into the code generated by the embedding (top-level) plugin. The following values will be returned according to the given modifier:
 	<variablelist>
 	<varlistentry>
 	<term>No modifier ("")</term>
 	<listitem><para>Returns the full code, &ie; the sections "preprocess", "calculate", "printout", and (but not "preview") concatenated to one string.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"preprocess"</term>
 	<listitem><para>Returns only the preprocess section of the code</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"calculate"</term>
 	<listitem><para>Returns only the calculate section of the code</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"printout"</term>
 	<listitem><para>Returns only the printout section of the code</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>"preview"</term>
 	<listitem><para>Returns the preview section of the code</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 </variablelist>
 </sect1>
 
 <sect1 id="globalxmlelements">
 	<title>General purpose elements to be used in any XML file (<literal role="extension">.xml</literal>, <literal role="extension">.rkh</literal>, &pluginmap;)</title>
 	<variablelist>
 	<varlistentry>
 	<term>&lt;snippets&gt;</term>
 	<listitem><para>Allowed as a direct child of the &lt;document&gt; node and only there. Should be placed near the top of the file. See <link linkend="snippets">section on using snippets</link>. Only one &lt;snippets&gt; element may be present. Optional, no attributes.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;snippet&gt;</term>
 	<listitem><para>Defines a single snippet. Allowed only as a direct child of the &lt;snippets/&gt; element. Attributes:
 		<variablelist>
 		<varlistentry>
 		<term>&lt;id&gt;</term>
 		<listitem><para>An identifier string for the snippet. Required.</para></listitem>
 		</varlistentry>
 		</variablelist></para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;insert&gt;</term>
 	<listitem><para>Insert the contents of a &lt;snippet&gt;. Allowed anywhere. Attributes:
 		<variablelist>
 		<varlistentry>
 		<term>&lt;snippet&gt;</term>
 		<listitem><para>The identifier string of the snippet to insert. Required.</para></listitem>
 		</varlistentry>
 		</variablelist></para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;include&gt;</term>
 	<listitem><para>Include the contents of another XML file (everything inside the &lt;document&gt; element of that file). Allowed anywhere. Attributes:
 		<variablelist>
 		<varlistentry>
 		<term>&lt;file&gt;</term>
 		<listitem><para>The filename, relative to the directory, the current file is in. Required.</para></listitem>
 		</varlistentry>
 		</variablelist></para></listitem>
 	</varlistentry>
 	</variablelist>
 </sect1>
 
 <sect1 id="xmlelements"><title>Elements to be used in the XML description of the plugin</title>
 <para>Properties held by the elements are listed in a <link linkend="elementproperties">separate section</link>.</para>
 
 <sect2 id="generalelements"><title>General elements</title>
 <variablelist>
 <varlistentry>
 <term>&lt;document&gt;</term>
 <listitem><para>Needs to be present in each description.xml-file as the root-node. No special function. No attributes</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;about&gt;</term>
 <listitem><para>Information about this plugin (author, licence, &etc;). This element is allowed in both an individual plugin's .xml file, and in &pluginmap; files. Refer to the <link linkend="pluginmapelements">&pluginmap; file reference</link> for reference details, <link linkend="chapter_about_information">the chapter on 'about' information</link> for an introduction.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;code&gt;</term>
 <listitem><para>Defines where to look for the JS template to the plugin. Use only once per file, as a direct child of the document-tag. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>file</parameter></term>
 	<listitem><para>Filename of the JS template, relative to the directory the plugin-xml is in</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;help&gt;</term>
 <listitem><para>Defines where to look for the help file for the plugin. Use only once per file, as a direct child of the document-tag. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>file</parameter></term>
 	<listitem><para>Filename of the help file, relative to the directory the plugin-xml is in</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;copy&gt;</term>
 <listitem><para>Can be used as a child (direct or indirect) of the main layout elements, &ie; &lt;dialog&gt; and &lt;wizard&gt;. This is used to copy an entire block a xml elements 1:1. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>The ID to look for. The &lt;copy&gt; tag will look for a previous XML element that has been given the same ID, and copy it including all descendant elements.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>copy_element_tag_name</parameter></term>
 	<listitem><para>In some few cases, you will want an almost literal copy, but change the tag-name of the element to copy. The most important example of this is, when you want to copy an entire &lt;tab&gt; from a dialog interface to the &lt;page&gt; of a wizard interface. In this case, you'd set copy_element_tag_name="page" to do this conversion automatically.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 </variablelist>
 </sect2>
 
 <sect2 id="interfaceelements"><title>Interface definitions</title>
 <variablelist>
 <varlistentry>
 <term>&lt;dialog&gt;</term>
 <listitem><para>Defines a dialog-type interface. Place the GUI-definition inside this tag. Use only once per file, as a direct child of the document-tag. At least one of "dialog" or "wizard" tags is required for a plugin. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Caption for the dialog</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>recommended</parameter></term>
 	<listitem><para>Should the dialog be used as the "recommended" interface (&ie; the interface that will be shown by default, unless the user has configured RKWard to default to a specific interface)? This attribute does not currently have an effect, as it is implicitly "true", unless the wizard is recommended.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;wizard&gt;</term>
 <listitem><para>Defines a wizard-type interface. Place the GUI-definition inside this tag. Use only once per file, as a direct child of the document-tag. At least one of "dialog" or "wizard" tags is required for a plugin. Accepts only &lt;page&gt; or &lt;embed&gt;-tags as direct children. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Caption for the wizard</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>recommended</parameter></term>
 	<listitem><para>Should the wizard be used as the "recommended" interface (&ie; the interface that will be shown by default, unless the user has configured RKWard to default to a specific interface)? Optional, defaults to "false".</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 </variablelist>
 </sect2>
 
 <sect2 id="layoutelements"><title>Layout elements</title>
 <para>All elements in this section accept an attribute id="identifierstring". This attribute is optional for all elements. It can be used, for example, to hide/disable the entire layout element and all the elements contained therein (see <link linkend="logic">chapter GUI logic</link>). The id-string may not contain "." (dot) or ";" (semicolon), and should generally be limited to alphanumeric characters and the underscore ("_"). Only the additional attributes are listed.</para>
 <variablelist>
 <varlistentry>
 <term>&lt;page&gt;</term>
 <listitem><para>Defines a new page inside a wizard. Only allowed as a direct child of a &lt;wizard&gt; element.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;row&gt;</term>
 <listitem><para>All direct children of a "row" tag will be placed left-to-right.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;column&gt;</term>
 <listitem><para>All direct children of a "column" tag will be placed top-to-bottom.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;stretch&gt;</term>
 <listitem><para>By default, elements in the GUI take up all the space that's available. For instance, if you have two columns side by side, the left one is packed with elements, but the right one only contains a lonely <command>&lt;radio&gt;</command>, the <command>&lt;radio&gt;</command> control will expand vertically, even though it does not really need the available space, and it will look ugly. In this case you really want to add a "blank" below the <command>&lt;radio&gt;</command>. For this, use the &lt;stretch&gt; element. It will simply use up some space. Don't overuse this element, usually it's a good idea for GUI elements to get all the available space, only sometimes will the layout become spaced out. The &lt;stretch&gt; element does not take any arguments, not even an "id". Also you can place no children inside the &lt;stretch&gt; element (in other words, you'll only ever use it as "&lt;stretch/&gt;")</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;frame&gt;</term>
 <listitem><para>Draws a frame/box around its direct children. Can be used to visually group related options. Layout inside a frame is top-to-bottom, unless you place a &lt;row&gt; inside. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Caption for the frame (optional)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>checkable</parameter></term>
 	<listitem><para>Frames can be made checkable. In this case, all contained elements will be disabled when the frame is unchecked, and enabled, when it is checked. (optional, defaults to "false")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>checked</parameter></term>
 	<listitem><para>For checkable frames only: Should the frame be checked by default? Defaults to "true". Not interpreted for non-checkable frames.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;tabbook&gt;</term>
 <listitem><para>Organizes elements in a tabbook. Accepts only &lt;tab&gt;-tags as direct children.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;tab&gt;</term>
 <listitem><para>Defines a page in a tabbook. Place the GUI-definition for the tab inside this tag. May be used only as a direct child of a &lt;tabbook&gt; tag. A &lt;tabbook&gt; should have at least two defined tabs. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Caption for the tab page (required)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;text&gt;</term>
 <listitem><para>Shows the text enclosed in this tag in the GUI. Some simple HTML-style markup is supported (notably <markup>&lt;b&gt;</markup>, <markup>&lt;i&gt;</markup>, <markup>&lt;p&gt;</markup>, and <markup>&lt;br/&gt;</markup>). Please keep formatting to a minimum, however. Inserting a completely empty line adds a hard line break. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>type</parameter></term>
 	<listitem><para>Type of the text. One of "normal", "warning" or "error". This influences the look of the text (optional, defaults to normal)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 </variablelist>
 </sect2>
 
 <sect2 id="activeelements"><title>Active elements</title>
 <para>All elements in this section accept an attribute id="identifierstring". This attribute is required for all elements. Only the additional attributes are listed. The id-string may not contain "." (dots).</para>
 <variablelist>
 
 <varlistentry>
 <term>&lt;varselector&gt;</term>
 <listitem><para>Provides a list of available objects from which the user can select one or more. Requires one or more &lt;varslot&gt;s as a counterpart to be useful. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the varselector (optional, defaults to "Select variable(s)")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;varslot&gt;</term>
 <listitem><para>Used in conjunction with a "varselector" to allow the user to select one or more variables. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the varslot (recommended, defaults to "Variable:")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>source</parameter></term>
 	<listitem><para>The varselector to fetch the selection from (required, unless you connect manually or using source_property)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>source_property</parameter></term>
 	<listitem><para>An arbitrary property to copy values from, when the select button is clicked. If specified, this overrides the "source"-attribute.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>required</parameter></term>
 	<listitem><para>Whether - for submitting the code - it is required that this varslot holds a valid value. See <link linkend="elementproperties">required-property</link> (optional, defaults to false)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>multi</parameter></term>
 	<listitem><para>Whether the varslot holds only one (default, "false"), or several objects</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>allow_duplicates</parameter></term>
 	<listitem><para>Whether the varslot may accept only unique objects (default, "false"), or if the same object may be added several times.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min_vars</parameter></term>
 	<listitem><para>Only meaningful if multi="true": Minimum number of vars to be selected for the selection to be considered valid (optional, defaults to "1")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min_vars_if_any</parameter></term>
 	<listitem><para>Only meaningful if multi="true": Some varslots may be considered valid, if, for instance, the varslot is either empty, or holds at least two values. This specifies how many variables have to be selected if any at all (2 in the example). (optional, defaults to "1")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max_vars</parameter></term>
 	<listitem><para>Only meaningful if multi="true": Maximum number of variables to select (optional, defaults to "0", which means no maximum)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>classes</parameter></term>
 	<listitem><para>If you specify one or more &r; classnames (separated by spaces (" ")), here, the varslot will only accept objects belonging to those classes (optional, <emphasis>use with great care</emphasis>, the user should not be prevented from making valid choices, and &r; has <emphasis>a lot</emphasis> of different classes!)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>types</parameter></term>
 	<listitem><para>If you specify one or more variables types (separated by spaced (" ")), here, the varslot will only accept objects of those types. Valid types are "unknown", "number", "string", "factor", "invalid". (Optional, <emphasis>use with great care</emphasis>, the user should not be prevented from making valid choices, and rkward does not always know the type of a variable)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>num_dimensions</parameter></term>
 	<listitem><para>The number of dimensions, an object needs to have. "0" (the default) means, any number of dimensions is acceptable. (optional, defaults to "0")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min_length</parameter></term>
 	<listitem><para>The minimum length, an object needs to have in order to be acceptable. (optional, defaults to "0")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max_length</parameter></term>
 	<listitem><para>The maximum length, an object needs to have in order to be acceptable. (optional, defaults to the largest integer number representable on the system)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;valueselector&gt;</term>
 <listitem><para>Provides a list of available strings (not R objects) to be selected in one or more accompanying &lt;valueslot&gt;s. String options can be defined using &lt;option&gt;-tags as direct children (see below), or set using dynamic <link linkend="elementproperties">properties</link>. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the valueselector (optional, defaults to no label)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;valueslot&gt;</term>
 <listitem><para>Used in conjunction with a &lt;valueselector&gt; to allow the user to select one or more string items. This element is mostly identical to &lt;varslot&gt;, and shares the same attributes, except for those which refer to properties of the acceptable items (&ie; classes, types, num_dimensions, min_length, max_length).</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;radio&gt;</term>
 <listitem><para>Defines a group of radio-exclusive buttons (only one can be selected at a time). Requires at least two &lt;option&gt;-tags as direct children. No other tags are allowed as children. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the radio control (recommended, defaults to "Select one:")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;dropdown&gt;</term>
 <listitem><para>Defines a group of options of which one and only one can be selected at the same time, using a dropdown list. This is functionally equivalent to a &lt;radio&gt;, but looks different. Requires at least two &lt;option&gt;-tags as direct children. No other tags are allowed as children. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the dropdown list (recommended, defaults to "Select one:")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;select&gt;</term>
 <listitem><para>Provides a list of available strings from which the user can select an arbitrary number. String options can be defined using &lt;option&gt;-tags as direct children (see below), or set using dynamic <link linkend="elementproperties">properties</link>. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the &lt;select&gt; (optional, defaults to no label)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;option&gt;</term>
 <listitem><para>Can only be used as a direct child of a &lt;radio&gt;, &lt;dropdown&gt;, &lt;valueselector&gt; or &lt;select&gt; element. Represents one selectable option in a radio control or dropdown list. As &lt;option&gt; elements are always part of one of the selection elements, they do not normally
 have an "id" of their own, but see below. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the option (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>value</parameter></term>
 	<listitem><para>The string value the parent element will return if this option is checked/selected (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>checked</parameter></term>
 	<listitem><para>Whether the option should be checked/selected by default "true" or "false". In a &lt;radio&gt; or &lt;dropdown&gt;, only one option may be set to <parameter>checked=</parameter><replaceable>"true"</replaceable>, and if no option is set to checked, the first option in the parent element will be checked/selected automatically. In a &lt;select&gt;, any number of options may be set to checked. (optional, default to "false")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>Specifying the "id" parameter for the &lt;option&gt; elements is optional (and in fact it's recommended, not to set an "id", unless you really need one). However, specifying an "id" will allow you to enable/disable &lt;option&gt;s, dynamically, by connecting to the boolean property <replaceable>id_of_radio.id_of_optionX.enabled</replaceable>. Currently this works for options inside &lt;radio&gt; or &lt;dropdown&gt;
 	elements, only; &lt;valueselector&gt; and &lt;select&gt; options do not currently support ids.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;checkbox&gt;</term>
 <listitem><para>Defines a check box, &ie; a single option that can either be set to on or off. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the check box (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>value</parameter></term>
 	<listitem><para>The value the check box will return if checked (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>value_unchecked</parameter></term>
 	<listitem><para>The value that will be returned if the check box is not checked (optional, defaults to "", &ie; an empty string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>checked</parameter></term>
 	<listitem><para>Whether the option should be checked by default "true" or "false" (optional, default to "false")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;frame&gt;</term>
 <listitem><para>The frame element is generally used as a pure layout element, and is listed in the section on <link linkend="layoutelements">layout elements</link>. However, it can also be
 made checkable, thus acting like a simple check box at the same time.
 </para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;input&gt;</term>
 <listitem><para>Defines a free text input field. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the input field (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>initial</parameter></term>
 	<listitem><para>Initial text of the text field (optional, defaults to "", &ie; an empty string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>size</parameter></term>
 	<listitem><para>One of "small", "medium", or "large". "large" defines a multi-line input field, "small", and "medium" are single line fields (optional, defaults to "medium")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>required</parameter></term>
 	<listitem><para>Whether - for submitting the code - it is required that this input is not empty. See <link linkend="elementproperties">required-property</link> (optional, defaults to false)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;matrix&gt;</term>
 <listitem><para>A table for entering matrix data (or vectors) in the GUI. <note><para>This input element is <emphasis>not</emphasis> optimized for entering editing large amounts of data. While there is no strict limit on the size of a &lt;matrix&gt;, in general it should not exceed around ten rows / columns. If you expect larger data, allow users to select it as an R object (which may be a good idea as an alternative option, in almost <emphasis>every</emphasis> instance where you use a matrix element).</para></note> Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the table (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>mode</parameter></term>
 	<listitem><para>One of "integer", "real", or "string". The type of data that will be accepted in the table (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min</parameter></term>
 	<listitem><para>Minimum acceptable value (for matrices of type "integer" or "real") (optional, defaults to the smallest representable value)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max</parameter></term>
 	<listitem><para>Maximum acceptable value (for matrices of type "integer" or "real") (optional, defaults to the largest representable value)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>allow_missings</parameter></term>
 	<listitem><para>Whether missing (empty) values are allowed in the matrix. This is implied for matrices or mode "string"  (optional, defaults to false).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>allow_user_resize_columns</parameter></term>
 	<listitem><para>When set to true, the user can add columns by typing on the rightmost (inactive) cells  (optional, defaults to true).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>allow_user_resize_rows</parameter></term>
 	<listitem><para>When set to true, the user can add rows by typing on the bottommost (inactive) cells  (optional, defaults to true).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>rows</parameter></term>
 	<listitem><para>Number of rows in the matrix. Has no effect for allow_user_resize_rows="true". <note><para>This can also be controlled by setting the "rows" property".</para></note> (optional, defaults to 2).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>columns</parameter></term>
 	<listitem><para>Number of columns in the matrix. Has no effect for allow_user_resize_columns="true". <note><para>This can also be controlled by setting the "columns" property".</para></note> (optional, defaults to 2).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min_rows</parameter></term>
 	<listitem><para>Minimum number of rows in the matrix. The matrix will refuse shrink below this size. (optional, defaults to 0; see also: <parameter>allow_missings</parameter>.).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min_columns</parameter></term>
 	<listitem><para>Minimum number of columns in the matrix. The matrix will refuse shrink below this size. (optional, defaults to 0; see also: <parameter>allow_missings</parameter>.).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>fixed_height</parameter></term>
 	<listitem><para>Force the GUI element to stay at its initial height. Do not use in combination with matrices, where the number of rows may change in any way. Useful, esp. when creating a vector input element (columns="1"). With this option set to true, no horizontal scroll bar will be shown, even in the matrix exceeds the available width (as this would affect the height). (optional, defaults to false).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>fixed_width</parameter></term>
 	<listitem><para>Slightly misnamed: Assume the column count will not change. The last (or typically only) column will be stretched to take up the available width. Do not use in combination with matrices, where the number of columns may change in any way. Useful, esp. when creating a vector input element (rows="1"). (optional, defaults to false).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>horiz_headers</parameter></term>
 	<listitem><para>Strings to ues for the horizontal header, separated by ";". The header will be hidden, if set to "". (optional, defaults to column number).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>vert_headers</parameter></term>
 	<listitem><para>Strings to ues for the vertical header, separated by ";". The header will be hidden, if set to "". (optional, defaults to row number).</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;optionset&gt;</term>
 <listitem><para>A UI for repeating a set of options for an arbitrary number of items (<link linkend="optionset">introduction to optionsets</link>). Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>min_rows</parameter></term>
 	<listitem><para>If specified, the set will be marked invalid, unless it has at least this number of rows (optional, integer).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min_rows_if_any</parameter></term>
 	<listitem><para>Like min_rows, but will only be tested, if there is at least one row (optional, integer).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max_rows</parameter></term>
 	<listitem><para>If specified, the set will be marked invalid, unless it has at most this number of rows (optional, integer).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>keycolumn</parameter></term>
 	<listitem><para>Id of the column to act as keycolumn. An optionset with a (valid) keycolumn will act as a "driven" optionset. An optionset with no keycolumn will allow manual insertion / removal of items. The keycolumn must be marked as external. (optional, defaults to no keycolumn).</para></listitem>
 	</varlistentry>
 	</variablelist>
 Child-elements:
 	<variablelist>
 	<varlistentry>
 	<term>&lt;optioncolumn&gt;</term>
 	<listitem><para>Declares one optioncolumn of the set. For each value that you want to fetch from the optionset, you must declare a separate &lt;optioncolumn&gt;. Attributes:
 		<variablelist>
 			<varlistentry><term><parameter>id</parameter></term>
 			<listitem><para>The id of the optioncolumn (required, string).</para></listitem></varlistentry>
 			<varlistentry><term><parameter>external</parameter></term>
 			<listitem><para>Set to true, if the optioncolumn is controlled from outside the optionset (optional, boolean, defaults to false).</para></listitem></varlistentry>
 			<varlistentry><term><parameter>label</parameter></term>
 			<listitem><para>If given, the optioncolumn will be displayed in a column by that label (optional, string, defaults to not displayed).</para></listitem></varlistentry>
 			<varlistentry><term><parameter>connect</parameter></term>
 			<listitem><para>The property to connect this optioncolumn to, given as id inside the &lt;content&gt;-area. For external &lt;optioncolumn&gt;s, the corresponding value will be set to the externally set value. For regular (non-external) &lt;optioncolumn&gt;s,
 			the corresponding row of the &lt;optioncolumn&gt;-property, will be set when the property changes inside the content-area. (optional, string, defaults to not connected).</para></listitem></varlistentry>
 			<varlistentry><term><parameter>default</parameter></term>
 			<listitem><para>Only for external columns: The value to assume for this column, if no value is known for an entry. Rarely useful. (Optional, defaults to empty string)</para></listitem></varlistentry>
 		</variablelist>
 	</para></listitem></varlistentry>
 	<varlistentry>
 	<term>&lt;content&gt;</term>
 	<listitem><para>Declare the content / UI of the set. No attributes. All usual active, passive, and layout elements are allowed as childname elements. In addition, in earlier versions of RKWard (up to 0.6.3), the special child-element <command>&lt;optiondisplay&gt;</command> was allowed. This is obsolete in RKWard 0.6.4, and should simply be removed from existing plugins.
 	</para></listitem></varlistentry>
 	<varlistentry>
 	<term>&lt;logic&gt;</term>
 	<listitem><para>Optional specification of UI logic to apply <emphasis>inside</emphasis> the contents region the optionset. See <link linkend="logicelements">the reference on &lt;logic&gt;</link>
 	</para></listitem></varlistentry>
 	</variablelist>
 </para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;browser&gt;</term>
 <listitem><para>An element designed to select a single filename (or directory name). Note that this field will take any string, even though it is meant to be used for files, only:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the browser (optional, defaults to "Enter filename")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>initial</parameter></term>
 	<listitem><para>Initial text of the browser (optional, defaults to "", &ie; an empty string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>type</parameter></term>
 	<listitem><para>One of "file", "dir", or "savefile". To select an existing file, existing directory, or non-existing file, respectively (optional, defaults to "file")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>allow_urls</parameter></term>
 	<listitem><para>Whether (non-local) urls can be selected (optional, defaults to "false")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>filter</parameter></term>
 	<listitem><para>File type filter, &eg; ("*.txt *.csv" for .txt and .csv files). A separate entry for "All files" is added, automatically (optional, defaults to "", &ie; All files)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>required</parameter></term>
 	<listitem><para>Whether - for submitting the code - it is required that the field is not empty. Note that this does not necessarily mean, the selected filename is valid! See <link linkend="elementproperties">required-property</link> (optional, defaults to true)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;saveobject&gt;</term>
 <listitem><para>An element designed to select the name of an &r; object to save to (&ie; generally not already existing, in contrast to a varslot):
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the input (optional, defaults to "Save to:")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>initial</parameter></term>
 	<listitem><para>Initial text of the input (optional, defaults to "my.data")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>required</parameter></term>
 	<listitem><para>Whether - for submitting the code - it is required that the field holds a permissible object name. See <link linkend="elementproperties">required-property</link> (optional, defaults to true)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>checkable</parameter></term>
 	<listitem><para>In many use cases, saving to an &r; object is optional. In these cases, a check box can be integrated into the saveobject-element using this attribute. When set to true, the saveobject will be activated / deactivated by the check box. See the <link linkend="elementproperties">active-property</link> of saveobject (optional, defaults to false)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>checked</parameter></term>
 	<listitem><para>For checkable saveobject-elements, only: Whether the control is checked/enabled by default (optional, defaults to false)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;spinbox&gt;</term>
 <listitem><para>A spinbox in which the user can select a numeric value, using either direct keyboard input or small up/down arrows. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label for the spinbox (recommend, default to "Enter value:")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min</parameter></term>
 	<listitem><para>The lowest value the user is allowed to enter in the spinbox (optional, defaults to the lowest value technically representable in the spinbox)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max</parameter></term>
 	<listitem><para>The largest value the user is allowed to enter in the spinbox (optional, defaults to the highest value technically representable in the spinbox)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>initial</parameter></term>
 	<listitem><para>The initial value shown in the spinbox (optional, defaults to "0")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>type</parameter></term>
 	<listitem><para>One of "real" or "integer". Whether the spinbox will accept real numbers or only integers (optional, defaults to "real")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>default_precision</parameter></term>
 	<listitem><para>Only meaningful if the spinbox is of type="real". Specifies the default number of decimal places shown in the spinbox (only this many trailing zeros will be shown). When the user presses the up/down arrows, this decimal place will be changed. The user may still be able to enter values with a higher precision, however (see below) (optional, defaults to "2")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max_precision</parameter></term>
 	<listitem><para>The maximum number of digits that can be meaningfully represented (optional, defaults to "8")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;formula&gt;</term>
 <listitem><para>This advanced element allows the user to select a formula/set of interactions from selected variables. For instance for a GLM, this element can be used to allow the user to specify the interaction-terms in the model. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>fixed_factors</parameter></term>
 	<listitem><para>The ID of the varslot holding the selected fixed factors (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>dependent</parameter></term>
 	<listitem><para>The ID of the varslot holding the selected dependent variable (required)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;embed&gt;</term>
 <listitem><para>Embed a different plugin into this one (see <link linkend="embedding">chapter on embedding</link>). Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>component</parameter></term>
 	<listitem><para>The registered name of the component to embed (see <link linkend="pluginmap">chapter on registering components</link> (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>as_button</parameter></term>
 	<listitem><para>If set to "true", only a pushbutton will be placed in the embedding GUI, the embedded GUI will only be shown (in a separate window) when the pushbutton is pressed (optional, default is "false")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Only meaningful if as_button="true": The label of the button (recommend, default is "Options")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;preview&gt;</term>
-<listitem><para>Checkbox to toggle preview functionality. Attributes:
+<listitem><para>Checkbox to toggle preview functionality. Note that starting with version 0.6.5 of &kapp; <command>&lt;preview&gt;</command> preview elements are special-
+		cased in plugin dialogs (not wizards): They will be placed in the button-column, irrespective of where exactly they are defined in the UI. It is still a good idea to
+		define them at a sensible place in the layout, for backwards compatibility. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>Label of the box (optional, default is "Preview")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>mode</parameter></term>
 	<listitem><para>Type of preview. Supported types are "plot" (see <link linkend="preview_plots">chapter on graph previews</link>), "output" (see <link linkend="preview_output">chapter on (HTML) output previews</link>), "data" (see <link linkend="preview_data">data previews</link>), and "custom" (see <link linkend="preview_custom">custom previews</link>). (optional, default is "plot")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>placement</parameter></term>
-	<listitem><para>Placement of the preview: "attached" (to the main workplace), "detached" (standalone window), "docked" (attached to the plugin dialog) and "default" (default depending on type of preview). In general, it is recommended to leave this as the default setting for best UI-consistency (optional, default is "default")</para></listitem>
+	<listitem><para>Placement of the preview: "attached" (to the main workplace), "detached" (standalone window), "docked" (attached to the plugin dialog) and "default" (currently this is the same as "docked", but might become user-configuarable at some point). In general, it is recommended to leave this as the default setting for best UI-consistency (optional, default is "default")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>active</parameter></term>
 	<listitem><para>Whether the preview is active by default. In general, only docked previews should be made active by default, and even for these, there is a reason why the default is in-active previews (optional, default is "false")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 </variablelist>
 </sect2>
 
 <sect2 id="logicelements"><title>Logic section</title>
 <variablelist>
 <varlistentry>
 <term>&lt;logic&gt;</term>
 <listitem><para>The containing element for the logic section. All elements below are allowed only inside the &lt;logic&gt; element. The &lt;logic&gt; element is allowed only as a direct child of the &lt;document&gt; element (at most once per document), or of &lt;optionset&gt; elements (at most once per optionset). The document's logic section applies to both &lt;dialog&gt; and &lt;wizard&gt; GUIs in the same way.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;external&gt;</term>
 <listitem><para>Creates a new (string) property that is supposed to be connected to an outside property if the plugin gets embedded. See <link linkend="embedding_incomplete">section on "incomplete" plugins</link>. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>The ID of the new property (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>default</parameter></term>
 	<listitem><para>The default string value of the new property, &ie; the value used, if the property is not connected to an outside property (optional, defaults to an empty string)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;i18n&gt;</term>
 <listitem><para>Creates a new (string) property that is supposed to be provide an i18n'ed label. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>The ID of the new property (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>label</parameter></term>
 	<listitem><para>The label. This will be translated. (required)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;set&gt;</term>
 <listitem><para>Set a property to a fixed value (of course, if you additionally connect the property to some other property, the value does not remain fixed). For instance, if you embed a plugin, but want to hide some of its elements, you might set the visibility property of those elements to false. Useful esp. for embedded/embedding plugins. Note: If there are several &lt;set&gt; elements
 for a single <parameter>id</parameter>, the latest one to be defined takes precedence. This will sometimes be useful to rely on when using &lt;include&gt;d parts.
 Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>The ID of the property to set (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>to</parameter></term>
 	<listitem><para>The string value to set the property to (required). Note: For boolean properties such as visibility, enabledness, you'll typically set the to attribute to either to="true" or to="false".</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;convert&gt;</term>
 <listitem><para>Create a new boolean properties that depends on the state of one or more different properties. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>The ID of the new property (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>sources</parameter></term>
 	<listitem><para>The ids of the properties this property will depend on. One or more properties may be specified, separated by ";" (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>mode</parameter></term>
 	<listitem><para>The mode of conversion/operation. One of "equals", "notequals", "range", "and", "or". If in mode equals, the property will only be true, if the value of all of its sources equals the attribute standard (see below). If in at mode notequals, the property will only be true, if the value of all of its sources are different from the attribute standard (see below). If in mode range, the sources have to be numeric (integer or real). The property will only be true, if all sources are in the range specified by the attributes min and max (see below). If in mode and, the sources have to be boolean properties. The property will only be true, if all the sources are true simultaniously. If in mode or, the sources have to be boolean properties. The property will only be true, if at least one of the sources is true. (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>standard</parameter></term>
 	<listitem><para>Only meaningful in modes equals or notequals: the string value to compare against (required if in one of these modes)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>min</parameter></term>
 	<listitem><para>Only meaningful in mode range: the minimum value to compare against (optional, defaults to the lowest floating point number representable on the machine)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>max</parameter></term>
 	<listitem><para>Only meaningful in mode range: the maximum value to compare against (optional, defaults to the largest floating point number representable on the machine)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>require_true</parameter></term>
 	<listitem><para>If set to "true", the property will become required, and will only be considered valid, if its state is true/on. Hence, if the property is false, it will block the <guibutton>Submit</guibutton> button (optional, defaults to "false".
 		<caution><remark>If you use this, make sure the user can easily detect what's wrong, such as by showing an explanatory &lt;text&gt;)</remark></caution></para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;switch&gt;</term>
 <listitem><para>Create a new property that will relay to different target properties (or fixed strings) based on the value of a condition property. This allows to create logic similar to <function>if()</function> or <function>switch()</function> constructs. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>id</parameter></term>
 	<listitem><para>The ID of the new property (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>condition</parameter></term>
 	<listitem><para>The id of the condition property (required)</para></listitem>
 	</varlistentry>
 	</variablelist>
 Child elements:
 	<variablelist>
 	<varlistentry>
 	<term>&lt;true&gt;</term>
 	<listitem><para>If the condition property is boolean, you can specify the two child elements &lt;true&gt; and &lt;false&gt; (and only these). (Required, if &lt;false&gt; is also given)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;false&gt;</term>
 	<listitem><para>If the condition property is boolean, you can specify the two child elements &lt;true&gt; and &lt;false&gt; (and only these). (Required, if &lt;true&gt; is also given)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;case&gt;</term>
 	<listitem><para>If the condition property is not boolean, you can supply and arbitrary number of &lt;case&gt;-elements, one for each
 	value of the condition property that you want to match (at least one such element is required, if the condition property is not boolean)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;default&gt;</term>
 	<listitem><para>If the condition property is not boolean, the optional &lt;default&gt;-element, allows to specify the behavior, if no
 	&lt;case&gt; element is matches the value of the condition property (optional, allowed only once, in combination with one or more &lt;case&gt; elements).</para></listitem>
 	</varlistentry>
 	</variablelist>
 Child elements &lt;true&gt;, &lt;false&gt;, &lt;case&gt;, and &lt;default&gt; take the following attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>standard</parameter></term>
 	<listitem><para>Only for &lt;case&gt;-elements: The value to match the condition property against (required, string).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>fixed_value</parameter></term>
 	<listitem><para>A fixed string that should be supplied as the value of the &lt;switch&gt; property, if the current condition matches (required, if dynamic_value is not supplied).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>dynamic_value</parameter></term>
 	<listitem><para>The <parameter>id</parameter> of the target property that should be supplied as the value of the &lt;switch&gt; property, if the current condition matches (required, if fixed_value is not supplied).</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;connect&gt;</term>
 <listitem><para>Connects two properties. The client property will be changed whenever the governor property changes (but not the other way around!). Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>client</parameter></term>
 	<listitem><para>The ID of the client property, &ie; the property that will be adjusted (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>governor</parameter></term>
 	<listitem><para>The ID of the governor property, &ie; the property that will adjusts the client property. This may include a modifier (required)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term><parameter>reconcile</parameter></term>
 	<listitem><para>If "true", the client property will make adjust the governor property on connection in such a way that the governor property will only accept values that are also acceptable by the client (&eg; suppose the governor is a numeric property with min value "0", and the client is a numeric property with min value "100". The min of both properties will be adjusted to 100, if reconcile="true"). Generally works only for properties of the same basic type (optional, default to "false")</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;dependency_check&gt;</term>
 <listitem><para>Creates a boolean property that is true, if the specified dependencies are met, false otherwise. The xml syntax of the element is the same as that of the <command>&lt;dependencies&gt;</command> element, described in the <link linkend="pluginmapelements">&pluginmap; reference</link>. As of &rkward; 0.6.1, only the &rkward; and &r; version specifications are taken into account, not dependencies on packages or pluginmaps.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;script&gt;</term>
 <listitem><para>Define script code to control UI logic. See <link linkend="logic_scripted">the section on scripted GUJI logic</link> for details. The script code to run can be given either using the <parameter>"file"</parameter> attribute, or as a (commented) text of the element. The <command>&lt;script&gt;</command> element is not allowed in the <command>&lt;logic&gt;</command> section of an optionset. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term><parameter>file</parameter></term>
 	<listitem><para>File name of the script file. (required)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 </variablelist>
 </sect2>
 
 </sect1>	<!-- Elements in main XML -->
 
 <sect1 id="elementproperties"><title>Properties of plugin elements</title>
 <para>All <link linkend="layoutelements">layout elements</link>, and all <link linkend="activeelements">active elements</link> hold the following properties, accessible via "id_of_element.name_of_property":
 </para>
 <variablelist>
 <varlistentry>
 <term>visible</term>
 <listitem><para>Whether the GUI element is visible or not (boolean)</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>enabled</term>
 <listitem><para>Whether the GUI element is enabled or not (boolean)</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>required</term>
 <listitem><para>Whether the GUI element is required (to hold a valid setting) or not. Note that any element which is disabled or hidden is also implicitly non-required (boolean).</para></listitem>
 </varlistentry>
 </variablelist>
 <para>
 	In addition to this, some elements have additional properties you can connect to. Most active elements also have a "default" property whose value will be returned on calls to <function>getBoolean/getString/getList ("...")</function>, if no specific property was named, as described below.
 </para>
 
 <variablelist>
 <varlistentry>
 <term>&lt;text&gt;</term>
 <listitem><para>Default property is text
 	<variablelist>
 	<varlistentry>
 	<term>text</term>
 	<listitem><para>The text displayed (text)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;varselector&gt;</term>
 <listitem><para>No default property
 	<variablelist>
 	<varlistentry>
 	<term>selected</term>
 	<listitem><para>The objects currently selected. You probably do not want to use this. Used internally (RObject)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>root</term>
 	<listitem><para>The root/parent object of the objects offered for selection (RObject)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;varslot&gt;</term>
 <listitem><para>Default property is "available"
 	<variablelist>
 	<varlistentry>
 	<term>available</term>
 	<listitem><para>All objects held in the varslot (RObject)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>selected</term>
 	<listitem><para>Of the objects held in the varslot, those that are currently selected. You probably do not want to use this. Used internally (RObject)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>source</term>
 	<listitem><para>A copy of the objects selected in the corresponding varselector. You probably do not want to use this. Used internally (RObject)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;valueselector&gt;</term>
 <listitem><para>Default property is "selected"
 	<variablelist>
 	<varlistentry>
 	<term>selected</term>
 	<listitem><para>The strings currently selected. Modifier "labeled" to retrieve the corresponding labels. In a &lt;valueselector&gt; you probably do not want to use this, directly (only in a &lt;select&gt;). (read/write StringList)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>available</term>
 	<listitem><para>The list of string values to select from. (read/write StringList)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>labels</term>
 	<listitem><para>Labels to display for the string values. (read/write StringList)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;valueslot&gt;</term>
 <listitem><para>Same as &lt;varslot&gt;, but the properties are lists of strings, instead of RObjects.</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;radio&gt;</term>
 <listitem><para>Default property is "string"
 	<variablelist>
 	<varlistentry>
 	<term>string</term>
 	<listitem><para>The value of the currently selected option (string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>number</term>
 	<listitem><para>The number of the currently selected option (options are numbered top-to-bottom, starting at 0) (integer)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;dropdown&gt;</term>
 <listitem><para>Same as &lt;radio&gt;</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;select&gt;</term>
 <listitem><para>Same as &lt;valueselector&gt;</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;option&gt;</term>
 <listitem><para>No default property. "enabled" is the *only* property, and it is not currently available for options inside a &lt;select&gt; or &lt;valueselector&gt;. &lt;option&gt; does not have the "visible" or "required" properties.
 	<variablelist>
 	<varlistentry>
 	<term>enabled</term>
 	<listitem><para>Whether this single option should be enabled or disabled. In most cases you will enable/disable the entire &lt;radio&lt; or &lt;dropdown&lt;, instead. But this can be used to dynamically set the enabledness of a single option inside a &lt;radio&lt; or &lt;dropdown&lt; (bool)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;checkbox&gt;</term>
 <listitem><para>Default property is "state.labeled", which means that the values specified by the <parameter>value</parameter>, and <parameter>value_unchecked</parameter>-attributes are returned, <emphasis>not</emphasis> the displayed label of the check box.
 	<variablelist>
 	<varlistentry>
 	<term>state</term>
 	<listitem><para>State of the check box (on or off). Note that useful modifiers of this property (as of all boolean properties) are "not" and "labeled" (see <link linkend="propertytypes">types of properties</link>). However, often it is most useful to connect to the property with no modifier, &ie; "<emphasis>checkbox_id</emphasis>.state", which will return the state of the check box in a format suitable for use in an if statement (0 or 1). (boolean)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;frame&gt;</term>
 <listitem><para>Default property is "checked", if - and only if - the frame is checkable. For non-checkable frames, there is no default property.
 	<variablelist>
 	<varlistentry>
 	<term>checked</term>
 	<listitem><para>Available for checkable frames, only: state of the check box (on or off). Note that useful modifiers of this property (as of all boolean properties) are "not" and "numeric" (see <link linkend="propertytypes">types of properties</link>). (boolean)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;input&gt;</term>
 <listitem><para>Default property is "text"
 	<variablelist>
 	<varlistentry>
 	<term>text</term>
 	<listitem><para>Current text in the input field (string)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 	<term>&lt;matrix&gt;</term>
 	<listitem><para>Default property is "cbind".
 	<variablelist>
 		<varlistentry>
 			<term>rows</term>
 			<listitem><para>Number of rows in the matrix (integer). If the matrix allows the user to add / remove rows, this property should be treated as read-only. Otherwise, changing it, will change the size of the matrix.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term>columns</term>
 			<listitem><para>Number of columns in the matrix (integer). If the matrix allows the user to add / remove columns, this property should be treated as read-only. Otherwise, changing it, will change the size of the matrix.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term>tsv</term>
 			<listitem><para>Data in the matrix in tsv format (string; read-write). Note that compared to the usual tsv layout, <emphasis>columns</emphasis>, not rows, are separated by newline characters, and cells within a column are separated by tabulator characters.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term>0,1,2...</term>
 			<listitem><para>The data from a single column (0 for leftmost column). <function>getValue()</function>/<function>getString()</function> returns this as a single string, separated by "\n". However, the recommended way to get this is using <function>getList()</function>, which returns this column as an array of strings.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term>row.0,row.1,row.2...</term>
 			<listitem><para>The data from a single row (0 for topmost row). <function>getValue()</function>/<function>getString()</function> returns this as a single string, separated by "\n". However, the recommended way to get this is using <function>getList()</function>, which returns this column as an array of strings.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term>cbind</term>
 			<listitem><para>Data in a format suitable for pasting to R, wrapped in a cbind statement (string; read-only).</para></listitem>
 		</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 	<term>&lt;optionset&gt;</term>
 	<listitem><para>No default property.
 	<variablelist>
 		<varlistentry>
 			<term>row_count</term>
 			<listitem><para>Number of items in the optionset (integer). Read-only.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term>current_row</term>
 			<listitem><para>Currently active item in the optionset (integer). -1 for no active item. Read-write.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 			<term><emphasis>optioncolumn_ids</emphasis></term>
 			<listitem><para>For each &lt;optioncolumn&gt; you define, a string list property will be created with the specified id.</para></listitem>
 		</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;browser&gt;</term>
 <listitem><para>Default property is "selection"
 	<variablelist>
 	<varlistentry>
 	<term>selection</term>
 	<listitem><para>Current text (selected file name) in the browser (string)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;saveobject&gt;</term>
 <listitem><para>Default property is "selection"
 	<variablelist>
 	<varlistentry>
 	<term>selection</term>
 	<listitem><para>Full name of the selected object (string; read-only - to set this programmatically, use "parent", and "objectname")</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>parent</term>
 	<listitem><para>The parent object of the selected object. This is always an existing &r; object of a type that can contain other objects (&eg; a list or data.frame). When set to an empty string or an invalid object, ".GlobalEnv" is assumed (RObject)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>objectname</term>
 	<listitem><para>The base-name of the selected object, &ie; the string entered by the user (changed to a valid &r; name, if necessary) (string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>active</term>
 	<listitem><para>For checkable saveobjects, only: Whether the control is checked/enabled. Always true for non-checkable saveobjects (bool)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;spinbox&gt;</term>
 <listitem><para>Default property is either "int" or "real.formatted" depending on the spinbox's mode
 	<variablelist>
 	<varlistentry>
 	<term>int</term>
 	<listitem><para>Integer value held by the spinbox, or nearest integer, if in real mode (integer)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>real</term>
 	<listitem><para>Real value held by the spinbox (and integer, if in integer) (real)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;formula&gt;</term>
 <listitem><para>Default property is "model"
 	<variablelist>
 	<varlistentry>
 	<term>model</term>
 	<listitem><para>The current model string (string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>table</term>
 	<listitem><para>The data.frame holding the required variables. If variables from only one data.frame are used, the name of that data.frame is returned. Otherwise a new data.frame is constructed as required (string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>labels</term>
 	<listitem><para>If variables from multiple data.frames are involved, their names may get mangled (for instance, if both data.frames contain a variable named "x"). This returns a list with the mangled names as indices and the descriptive label as value (string)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>fixed_factors</term>
 	<listitem><para>The fixed factors. You probably do not want to use this. Used internally (RObject)</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>dependent</term>
 	<listitem><para>The dependent variable(s). You probably do not want to use this. Used internally (RObject)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;embed&gt;</term>
 <listitem><para>No default property
 	<variablelist>
 	<varlistentry>
 	<term>code</term>
 	<listitem><para>The code generated by the embedded plugin (code)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;preview&gt;</term>
 <listitem><para>Default property is "state"
 	<variablelist>
 	<varlistentry>
 	<term>state</term>
 	<listitem><para>Whether the preview box is checked (not necessarily whether the preview has already been shown) (boolean)</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;convert&gt;</term>
 <listitem><para>This element (used in the &lt;logic&gt; section) is special, in that is technically *is* a property, instead of just holding one or more properties. It is of boolean kind. Note that useful modifiers of this property (as of all boolean properties) are "not" and "numeric" (see <link linkend="propertytypes">types of properties</link>)</para></listitem>
 </varlistentry>
 
 <varlistentry>
 <term>&lt;switch&gt;</term>
 <listitem><para>This element (used in the &lt;logic&gt; section) is special, in that is technically *is* a (string) property, instead of just holding one or more properties. It allows to switch between several target properties depending on the value of a condition property, or to re-map values of the condition property. Any modifiers that you supply are passed on to the target properties, thus, &eg; if all target
 properties are RObject properties, you can use the "shortname" modifier on the switch, too. However, if the target properties are of
 different types, using modifiers may lead to errors. For <replaceable>fixed_value</replaceable>s, any modifier is dropped, silently. Note that target properties, when accessed through a switch, are always read-only!</para></listitem>
 </varlistentry>
 
 </variablelist>
 </sect1>
 
 <sect1 id="standard_embeddable_plugins"><title>Embeddable plugins shipped with the official RKWard release</title>
 <para>A number of embeddable plugins is shipped with &rkward;, and can be used in your own plugins. Detailed documentation is currently available
 	only in these plugins source or help files. However, here is a list to give you a quick overview of what is available:</para>
 <table frame='all'><title>Standard embeddable plugins</title>
 <tgroup cols='4'>
 <thead>
 <row>
   <entry>ID</entry>
   <entry>Pluginmap</entry>
   <entry>Description</entry>
   <entry>Example usage</entry>
 </row>
 </thead>
 <tbody>
 <row>
   <entry>rkward::plot_options</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Provides a wide range of options for plots. Most plotting plugins utilize this.</entry>
   <entry>Plots->Barplot, most other plotting plugins</entry>
 </row>
 <row>
   <entry>rkward::color_chooser</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Very simple plugin for specifying a color. Current implementation provides a list of color names. Future implementations may provide
          more elaborate color picking.</entry>
   <entry>Plots->Histogram</entry>
 </row>
 <row>
   <entry>rkward::plot_stepfun_options</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Step function plot options</entry>
   <entry>Plots->ECDF plot</entry>
 </row>
 <row>
   <entry>rkward::histogram_options</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Histogram (plot) options</entry>
   <entry>Plots->Histogram</entry>
 </row>
 <row>
   <entry>rkward::barplot_embed</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Barplot options</entry>
   <entry>Plots->Barplot</entry>
 </row>
 <row>
   <entry>rkward::one_var_tabulation</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Provides tabulation on a single variable.</entry>
   <entry>Plots->Barplot</entry>
 </row>
 <row>
   <entry>rkward::limit_vector_length</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Limit the length of a vector (to the n largest or smallest elements).</entry>
   <entry>Plots->Barplot</entry>
 </row>
 <row>
   <entry>rkward::grid</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Add grid to a plot</entry>
   <entry>In an existing plot window: Edit->Draw grid.</entry>
 </row>
 <row>
   <entry>rkward::level_select</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Provides a &lt;valueselector&gt; filled with the levels (or unique values) of a vector.</entry>
   <entry>Data->Recode Categorical data</entry>
 </row>
 <row>
   <entry>rkward::multi_input</entry>
   <entry>embedded.pluginmap</entry>
   <entry>Combines spinbox, input and radio controls to provide input for character, numeric, logical data.</entry>
   <entry>Data->Recode Categorical data</entry>
 </row>
 </tbody>
 </tgroup>
 </table>
 </sect1>
 
 <sect1 id="pluginmapelements"><title>Elements for use in &pluginmap; files</title>
 <variablelist>
 <varlistentry>
 <term>&lt;document&gt;</term>
 <listitem><para>Needs to be present in each &pluginmap; file as the root-node (exactly once). Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>base_prefix</term>
 	<listitem><para>Filenames specified in the &pluginmap; file are assumed to be relative to the directory of the &pluginmap; file + the prefix you specify here. Useful, esp., if all your components are located below a single subdirectory.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>namespace</term>
 	<listitem><para>A namespace for the component ids. When looking up components for embedding, the components will beretrievable via a string "namespace::component_id". Set to "rkward" for now.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>An optional identifier string for this &pluginmap;. Specifying this allows third authors to refer to and load your &pluginmap; from theirs (see <link linkend="chapter_dependencies">chapter on handling dependencies</link>.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>priority</term>
 	<listitem><para>One of <replaceable>"hidden"</replaceable>, <replaceable>"low"</replaceable>, <replaceable>"medium"</replaceable>, or <replaceable>"high"</replaceable>. &pluginmap;s with priority "medium" or "high" are activated, automatically, when &rkward; first finds them. Use <replaceable>priority="hidden"</replaceable> for &pluginmap;s that are not meant to be activated, directory (only meant for inclusion). In the current implementation this does not actually hide the &pluginmap;, however. (Optional, defaults to "medium").</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;dependencies&gt;</term>
 <listitem><para>This element, specifying dependencies, is allowed as a direct child of the &lt;document&gt; element (once), and as a child of &lt;component&gt; elements (once for each &lt;component&gt; element). Specifies the dependencies that must be met in order to use the plugin(s). See the <link linkend="chapter_dependencies">chapter on dependencies</link> for an overview. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>rkward_min_version, rkward_max_version</term>
 	<listitem><para>Minimum and maximum allowed version of &rkward;. Version specifications may include non-numeric suffixes, like "0.5.7z-devel1". If a specified dependency is not met, the plugin(s) it applies to <emphasis>will be ignored</emphasis>. <link linkend="sect_dependencies_rkward_version">More information</link>. Optional; if not specified, no minimum / maximum version of &rkward; will be required.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>R_min_version, R_max_version</term>
 	<listitem><para>Minimum and maximum allowed version of &rkward;. Version specifications may <emphasis>not</emphasis> include non-numeric suffixes, like "0.5.7z-devel1". The R version dependency will be shown on the plugins' help pages, but does not have any direct effect, as of &rkward; 0.6.1. <link linkend="sect_dependencies_r_version">More information</link>. Optional; if not specified, no minimum / maximum version of &r; will be required.</para></listitem>
 	</varlistentry>
 	</variablelist>
 Child elements:
 	<variablelist>
 	<varlistentry>
 	<term>&lt;package&gt;</term>
 	<listitem><para>Adds a dependency on a specific &r; package. Attributes: 
 		<variablelist>
 		<varlistentry>
 		<term>name</term>
 		<listitem><para>Package name (required).</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>min_version, max_version</term>
 		<listitem><para>Minimum / maximum allowed version (optional).</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>repository</term>
 		<listitem><para>Repository where the package can be found. Optional, but highly recommended, if the package is not available on CRAN.</para></listitem>
 		</varlistentry>
 		</variablelist>
 	</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>&lt;pluginmap&gt;</term>
 	<listitem><para>Adds a dependency on a specific &rkward; &pluginmap;. Attributes: 
 		<variablelist>
 		<varlistentry>
 		<term>name</term>
 		<listitem><para>Id string of the required &pluginmap; (required).</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>min_version, max_version</term>
 		<listitem><para>Minimum / maximum allowed version (optional).</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>url</term>
 		<listitem><para>URL where the &pluginmap; can be found. Required.</para></listitem>
 		</varlistentry>
 		</variablelist>
 	</para></listitem>
 	</varlistentry>
 	</variablelist>
 </para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;about&gt;</term>
 <listitem><para>May be present exactly once as a direct child of the &lt;document&gt; element. Contains meta information on the &pluginmap; (or plugin). See the <link linkend="chapter_about_information">chapter on 'about' information</link> for an overview. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>name</term>
 	<listitem><para>User visible name. Optional. Does not have to be the same as the "id".</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>version</term>
 	<listitem><para>Version number. Optional. The format is not restricted, but to be on the safe side, please follow common versioning schemes such as "x.y.z".</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>releasedate</term>
 	<listitem><para>Release date specification. Optional in format "YYYY-MM-DD".</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>shortinfo</term>
 	<listitem><para>A <emphasis>short</emphasis> description of the plugin / &pluginmap;. Optional.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>url</term>
 	<listitem><para>URL where more information can be found. Optional, but recommended.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>copyright</term>
 	<listitem><para>Copyright specification, &eg; "2012-2013 by John Doe". Optional, but recommended.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>licence</term>
 	<listitem><para>License specification, &eg; "GPL" or "BSD". Please make sure to accompany your files with a complete copy of the relevant licence! Optional, but recommended.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>category</term>
 	<listitem><para>Category of plugin(s), &eg; "Item response theory". As of &rkward; 0.6.1, no categories are predefined. Optional.</para></listitem>
 	</varlistentry>
 	</variablelist>
 Child elements:
 	<variablelist>
 	<varlistentry>
 	<term>&lt;author&gt;</term>
 	<listitem><para>Adds information on an author. Attributes: 
 		<variablelist>
 		<varlistentry>
 		<term>name, given, family</term>
 		<listitem><para>Either specify the full name for <parameter>name</parameter>, or specify both <parameter>given</parameter> and <parameter>family</parameter>, separately.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>role</term>
 		<listitem><para>Author role description (optional).</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>email</term>
 		<listitem><para>E-mail address, where author can be contacted. Required. May be set to the rkward-devel mailing list, if you are subscribed, and your plugin is meant to be included in the official &rkward; release.</para></listitem>
 		</varlistentry>
 		<varlistentry>
 		<term>url</term>
 		<listitem><para>URL with more information on the author, &eg; homepage (optional).</para></listitem>
 		</varlistentry>
 		</variablelist>
 	</para></listitem>
 	</varlistentry>
 	</variablelist>
 </para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;components&gt;</term>
 <listitem><para>Needs to be present exactly once as a direct child of the &lt;document&gt; element. Contains the individual &lt;component&gt;-elements described below. No attributes.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;component&gt;</term>
 <listitem><para>One or more &lt;component&gt; elements should be given as direct children of the &lt;components&gt; element (and only there). Registers a component/plugin with rkward. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>type</term>
 	<listitem><para>For future extension: The type of component/plugin. Always set to "standard" for now (the only type currently supported).</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>The ID by which this component can be retrieved (for placing it in the menu (see below), or for embedding). See &lt;document/gt;-namespace above.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>file</term>
 	<listitem><para>Required at least for components of type="standard": The filename of the XML file describing the GUI.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>label</term>
 	<listitem><para>The label for this component, when placed in the menu hierarchy.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;attribute&gt;</term>
 <listitem><para>Defines an attribute of a component. Only meaningful for <link linkend="context_import">import plugins</link> so far. Only allowed as a direct child of &lt;component&gt;. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>Id of the attribute</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>value</term>
 	<listitem><para>Value of the attribute</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>labels</term>
 	<listitem><para>Label associated with the attribute</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;hierarchy&gt;</term>
 <listitem><para>Needs to be present exactly once as a direct child of the &lt;document&gt; element. Described where the components declared above should be placed in the menu hierarchy. Accepts only &lt;menu&gt; elements as direct children. No attributes.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;menu&gt;</term>
 <listitem><para>One or more &lt;menu&gt; elements should be given as direct children of the &lt;hierarchy&gt; element. Declares a new (sub-)menu. If a menu by the given ID (see below) already exists, the two menus are merged. The &lt;menu&gt; element is allowed either as a direct child of the &lt;hierarchy&gt; element (top level menu), or as the direct child on any other &lt;menu&gt; element (sub-menu). Conversely, the &lt;menu&gt; element accepts other &lt;menu&gt; elements or &lt;entry&gt; elements as children. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>An identifier string of the menu. Useful, when menu definitions are read from several &pluginmap; files, to make sure plugins can be placed in the same menu(s). Some menu-ids such as "file" refer to predefined menus (in this case the "File" menu). Be sure to check with existing &pluginmap; files to use consistent ids.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>label</term>
 	<listitem><para>A label for the menu.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>group</term>
 	<listitem><para>Allows to control ordering of menu entries. See <link linkend="pluginmap_grouping">menu item ordering</link>. Optional.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;entry&gt;</term>
 <listitem><para>A menu entry, &ie; a menu option to invoke a plugin. May be used only as a direct child of a &lt;menu&gt; element, accepts no child elements. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>component</term>
 	<listitem><para>The ID of the component that should be invoked, when this menu entry is activated.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>group</term>
 	<listitem><para>Allows to control ordering of menu entries. See <link linkend="pluginmap_grouping">menu item ordering</link>. Optional.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;group&gt;</term>
 <listitem><para>Declares a group of items in the menu. See <link linkend="pluginmap_grouping">menu item ordering</link>. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>The name of this group.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>separated</term>
 	<listitem><para>Optional. If set to "true" the item in this group will be visually separated from surrounding items.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>group</term>
 	<listitem><para>The name of the group to append this group to (optional).</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;context&gt;</term>
 <listitem><para>Declares the entries in a <link linkend="contextualized_plugins">context</link>. Only allowed as a direct child of the &lt;document&gt; tag. Accepts only &lt;menu&gt; tags as direct children. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>The ID of the context. Only two contexts are implemented so far: "x11" and "import".</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;require&gt;</term>
 <listitem><para>Include another &pluginmap; file. This &pluginmap; file is only loaded once, even if it is &lt;require&gt;d from several other files. The most important use case is to include a pluginmap file, which declares some components, which are embedded by components declared in this &pluginmap;. &lt;require&gt;-elements are only allowed as direct children of the &lt;document&gt;-node. Attributes:
 	<variablelist>
 	<varlistentry>
 	<term>file</term>
 	<listitem><para>The filename of the &pluginmap; to include. This is seen relative to the directory of the current &pluginmap; file + the base_prefix (see above, &lt;document&gt;-element). If you do not know the relative path to the &pluginmap; to be included, use the <parameter>map</parameter> attribute to refer to it by id, instead.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>map</term>
 	<listitem><para>To include a &pluginmap; file from a different package (or an &rkward; &pluginmap; from your external &pluginmap;, you can refer to it by its <replaceable>namespacename::id</replaceable>, as specified in the required &pluginmap;s &lt;document&gt; element. Inclusion will fail, if no &pluginmap; by that id is known (&eg; not installed on the user's system). You should use this method for including &pluginmap;s outside your package, only. For maps inside your package, specifying a relative path (<parameter>file</parameter> attribute) is faster, and more reliable.
 	</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 </variablelist>
 </sect1>
 
 <sect1 id="helpfileelements"><title>Elements for use in .rkh (help) files</title>
 <variablelist>
 <varlistentry>
 <term>&lt;document&gt;</term>
 <listitem><para>Needs to be present in each <literal role="extension">.xml</literal> file as the root-node (exactly once). No attributes.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;title&gt;</term>
 <listitem><para>Title of the help page. This is <emphasis>not</emphasis> interpreted for help pages for a plugin (this takes the title from the plugin itself), only for stand-alone pages. No attributes. The text contained within the &lt;title&gt; tag will become the caption of the help page. May only be defined once, as a direct child of the &lt;document&gt; node.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;summary&gt;</term>
 <listitem><para>A short summary of the help page (or what this plugin is used for). This will always be shown at the top of the help page. No attributes. The text contained within the &lt;summary&gt; tag will be displayed. Recommended but not required. May only be defined once, as a direct child of the &lt;document&gt; node.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;usage&gt;</term>
 <listitem><para>A slightly more elaborate summary of the usage. This will always be shown directly after the &lt;summary&gt;. No attributes. The text contained within the &lt;usage&gt; tag will be displayed. Recommended for plugin help pages, but not required. May only be defined once, as a direct child of the &lt;document&gt; node.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;section&gt;</term>
 <listitem><para>A general purposes section. May be used any number of times as a direct child of the &lt;document&gt; node. These sections are displayed in the order of their definition, but all <emphasis>after</emphasis> the &lt;usage&gt; section and <emphasis>before</emphasis> the &lt;settings&gt; section. The text contained within the &lt;section&gt; tag will be displayed.
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>An identifier needed to jump to this section from the navigation bar (or a link). Needs to be unique within the file. Required, no default.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>title</term>
 	<listitem><para>The title (caption) of this section. Required, no default.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>short_title</term>
 	<listitem><para>A short title suitable to be displayed in the navigation bar. Optional, defaults to the full title.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;settings&gt;</term>
 <listitem><para>Defines the section containing reference on the various GUI settings. Only meaningful and only used for plugin related help pages. Use as a direct child of the &lt;document&gt;. May contain only &lt;setting&gt; and &lt;caption&gt; elements as direct children. No attributes.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;setting&gt;</term>
 <listitem><para>Explains a single setting in the GUI. Only allowed as a direct child of the &lt;settings&gt; element. The text contained within the element is displayed.
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>The ID of the setting in the plugin .xml. Required, no default.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>title</term>
 	<listitem><para>An optional title for the setting. If omitted (omission is recommended in most cases), the title will be taken from the plugin .xml.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;caption&gt;</term>
 <listitem><para>A caption to visually group several settings. May only be used as a direct child of the &lt;settings&gt; element.
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>The ID of the corresponding element (typically a &lt;frame&gt;, &lt;page&gt; or &lt;tab&gt;) in the plugin .xml.</para></listitem>
 	</varlistentry>
 	<varlistentry>
 	<term>title</term>
 	<listitem><para>An optional title for the caption. If omitted (omission is recommended in most cases), the title will be taken from the plugin .xml.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;related&gt;</term>
 <listitem><para>Defines a section containing links to further related information. Will always be displayed after the &lt;settings&gt; section. No attributes. The text contained within the &lt;related&gt; tag will be displayed. Typically this will contain an HTML-style list. Recommended for plugin help pages, but not required. May only be defined once, as a direct child of the &lt;document&gt; node.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;technical&gt;</term>
 <listitem><para>Defines a section containing technical information of no relevance to end users (such as internal structure of the plugin). Will always be displayed last in a help page. No attributes. The text contained within the &lt;related&gt; tag will be displayed. Not required, and not recommended for most plugin help pages. May only be defined once, as a direct child of the &lt;document&gt; node.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;link&gt;</term>
 <listitem><para>A link. Can be used in any of the sections described above.
 	<variablelist>
 	<varlistentry>
 	<term>href</term>
 	<listitem><para>The target url. Note that several rkward specific URLs are available. See <link linkend="pluginhelp">section on writing help pages</link> for details.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;label&gt;</term>
 <listitem><para>Inserts the value of a UI label. Can be used in any of the sections described above.
 	<variablelist>
 	<varlistentry>
 	<term>id</term>
 	<listitem><para>The id of the element in the plugin, of which to copy the <replaceable>label</replaceable>-attribute.</para></listitem>
 	</varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry>
 <term>&lt;various html tags&gt;</term>
 <listitem><para>Most basic html tags are allowed within the sections. Please keep manual formatting to a minimum, however.</para></listitem>
 </varlistentry>
 </variablelist>
 </sect1>
 
 <sect1 id="guilogic_functions"><title>Functions available for GUI logic scripting</title>
 <variablelist>
 <varlistentry><term>Class "Component"</term>
 <listitem><para>Class which represents a single component or component-property. The most important instance of this class is the variable "gui" which is predefined as the root property of the current component. The following methods are available for instances of class "Component":
 	<variablelist>
 	<varlistentry><term>absoluteId(base_id)</term><listitem><para>Returns the absolute ID of <emphasis>base_id</emphasis>, or - if base_id is omitted - the identifier of the component.</para></listitem></varlistentry>
 	<varlistentry><term>getValue(id)</term><listitem><para>Discouraged. Use <function>getString(), getBoolean(), or getList()</function>, instead. Returns the value of the given child property. Returns the value of this property, if ID is omitted.</para></listitem></varlistentry>
 	<varlistentry><term>getString(id)</term><listitem><para>Returns the value of the given child property as a string. Returns the value of this property, if ID is omitted.</para></listitem></varlistentry>
 	<varlistentry><term>getBoolean(id)</term><listitem><para>Returns the value of the given child property as a boolean (if possible). Returns the value of this property, if ID is omitted.</para></listitem></varlistentry>
 	<varlistentry><term>getList(id)</term><listitem><para>Returns the value of the given child property as an array of strings (if possible). Returns the value of this property, if ID is omitted.</para></listitem></varlistentry>
 	<varlistentry><term>setValue(id, value)</term><listitem><para>Set the value of the given child property to <emphasis>value</emphasis>.</para></listitem></varlistentry>
 	<varlistentry><term>getChild(id)</term><listitem><para>Return an instance of the child-property with the given <emphasis>id</emphasis>.</para></listitem></varlistentry>
 	<varlistentry><term>addChangeCommand(id, command)</term><listitem><para>Execute <emphasis>command</emphasis> whenever the child property given by <emphasis>id</emphasis> changes.</para></listitem></varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry><term>Class "RObject"</term>
 <listitem><para>Class which represents a single &r; object. An instance of this class can be obtained by using <command>makeRObject(objectname)</command>. The following methods are available for instances of class "RObject": <warning><remark>If any commands are still pending in the backend, the information provided by these methods can be out-of-date by the time that the plugin code is run. Do <emphasis>not</emphasis> rely on it for critical operations (risking loss of data).</remark></warning>
 	<variablelist>
 	<varlistentry><term>getName()</term><listitem><para>Returns the absolute name of the object.</para></listitem></varlistentry>
 	<varlistentry><term>exists()</term><listitem><para>Returns whether the object exists. You should generally check this before using any of the methods listed below.</para></listitem></varlistentry>
 	<varlistentry><term>dimensions()</term><listitem><para>Returns an array of dimensions (similar to <command>dim()</command> in R).</para></listitem></varlistentry>
 	<varlistentry><term>classes()</term><listitem><para>Returns an array of classes (similar to <command>class()</command> in R).</para></listitem></varlistentry>
 	<varlistentry><term>isClass(class)</term><listitem><para>Returns true, if the object is of class <emphasis>class</emphasis>.</para></listitem></varlistentry>
 	<varlistentry><term>isDataFrame()</term><listitem><para>Returns true, if the object is a data.frame.</para></listitem></varlistentry>
 	<varlistentry><term>isMatrix()</term><listitem><para>Returns true, if the object is a matrix.</para></listitem></varlistentry>
 	<varlistentry><term>isList()</term><listitem><para>Returns true, if the object is a list.</para></listitem></varlistentry>
 	<varlistentry><term>isFunction()</term><listitem><para>Returns true, if the object is a function.</para></listitem></varlistentry>
 	<varlistentry><term>isEnvironment()</term><listitem><para>Returns true, if the object is an environment.</para></listitem></varlistentry>
 	<varlistentry><term>isDataNumeric()</term><listitem><para>Returns true, if the object is a vector of numeric data.</para></listitem></varlistentry>
 	<varlistentry><term>isDataFactor()</term><listitem><para>Returns true, if the object is a vector of factor data.</para></listitem></varlistentry>
 	<varlistentry><term>isDataCharacter()</term><listitem><para>Returns true, if the object is a vector of character data.</para></listitem></varlistentry>
 	<varlistentry><term>isDataLogical()</term><listitem><para>Returns true, if the object is a vector of logical data.</para></listitem></varlistentry>
 	<varlistentry><term>parent()</term><listitem><para>Returns an instance of "RObject" representing the parent of this object.</para></listitem></varlistentry>
 	<varlistentry><term>child(childname)</term><listitem><para>Returns an instance of "RObject" representing the child <emphasis>childname</emphasis> of this object.</para></listitem></varlistentry>
 	</variablelist></para></listitem>
 </varlistentry>
 <varlistentry><term>Class "RObjectArray"</term>
 <listitem><para>An array of RObject instances. An instance of this class can be obtained by using <command>makeRObjectArray(objectnames)</command>. It is particularly useful when dealing with varslots which allow to select multiple objects.</para></listitem>
 </varlistentry>
 <varlistentry><term>include()-function</term>
 <listitem><para><command>include(filename)</command>can be used to include a separate JS file.</para></listitem>
 </varlistentry>
 <varlistentry><term>doRCommand()-function</term>
 <listitem><para><command>doRCommand(command, callback)</command> can be used to query R for information. Please read the section on <link linkend="querying_r_for_info">querying R from inside a plugin</link> for details, and caveats.</para></listitem>
 </varlistentry>
 </variablelist>
 </sect1>
 
 </appendix>
 
 <appendix id="troubleshooting">
 <title>Troubleshooting during plugin development</title>
 <para>
 So you've read all the documentation, did everything right, and still cannot get it to work? Don't worry, we'll work it out. First thing to do is: Activate "RKWard Debug Messages" - window (available from the "Windows" - menu, or right click on one of the tool bars), and then start your plugin, again. As a general rule of thumb, you should not see any output in the messages window when your plugin gets invoked, or at any other time. If there is one, it's likely related to your plugin. See if it helps you.
 </para>
 <para>
 If everything seems fine on the console, try to increase the debug-level (from the command line, using <command>rkward --debug-level 3</command>, or by setting debug level to 3 in Settings-&gt;Configure RKWard-&gt;Debug. Not all messages shown at higher debug levels necessarily indicate a problem, but chance are, your problem shows up somewhere between the messages.
 </para>
 <para>
 If you still cannot find out what's wrong, don't despair. We know this is complicated stuff, and - after all - possibly you've also come across a bug in &rkward;, and &rkward; needs to be fixed. Just write to the development mailing list, and tell us about the problem. We'll be happy to help you.
 </para>
 <para>
 Finally, even if you found out how to do it on your own, but found the documentation to be not-so-helpful or even wrong in some respects, please tell us on the mailing list as well, so we can fix/improve the documentation.
 </para>
 </appendix>
 
 <appendix id="license">
 <title>License</title>
 <!-- TRANS:CREDIT_FOR_TRANSLATORS -->
 &underFDL;
 </appendix>
 
 &documentation.index;
 </book>
 <!--
 Local Variables:
 mode: sgml
 sgml-minimize-attributes:nil
 sgml-general-insert-case:lower
 sgml-indent-step:0
 sgml-indent-data:nil
 End:
 -->
diff --git a/rkward/plugin/rkpreviewbox.cpp b/rkward/plugin/rkpreviewbox.cpp
index 3b54d46b..330bdaa8 100644
--- a/rkward/plugin/rkpreviewbox.cpp
+++ b/rkward/plugin/rkpreviewbox.cpp
@@ -1,277 +1,278 @@
 /***************************************************************************
                           rkpreviewbox  -  description
                              -------------------
     begin                : Wed Jan 24 2007
     copyright            : (C) 2007-2016 by Thomas Friedrichsmeier
     email                : thomas.friedrichsmeier@kdemail.net
  ***************************************************************************/
 
 /***************************************************************************
  *                                                                         *
  *   This program is free software; you can redistribute it and/or modify  *
  *   it under the terms of the GNU General Public License as published by  *
  *   the Free Software Foundation; either version 2 of the License, or     *
  *   (at your option) any later version.                                   *
  *                                                                         *
  ***************************************************************************/
 #include "rkpreviewbox.h"
 
 #include <qlayout.h>
 #include <qlabel.h>
 #include <qcheckbox.h>
 #include <qtimer.h>
 #include <QTextDocument>
 
 #include <klocale.h>
 #include <kvbox.h>
 
 #include "../rkglobals.h"
 #include "../rbackend/rinterface.h"
 #include "../misc/xmlhelper.h"
 #include "../misc/rkxmlguipreviewarea.h"
 #include "../windows/rkwindowcatcher.h"
 #include "../windows/rkworkplace.h"
 #include "rkstandardcomponent.h"
 #include "../debug.h"
 
 #define DO_PREVIEW 102
 
 RKPreviewBox::RKPreviewBox (const QDomElement &element, RKComponent *parent_component, QWidget *parent_widget) : RKComponent (parent_component, parent_widget) {
 	RK_TRACE (PLUGIN);
 
 	prior_preview_done = true;
 	new_preview_pending = false;
 
 	// get xml-helper
 	XMLHelper *xml = parent_component->xmlHelper ();
 
 	preview_mode = (PreviewMode) xml->getMultiChoiceAttribute (element, "mode", "plot;data;output;custom", 0, DL_INFO);
-	placement = (PreviewPlacement) xml->getMultiChoiceAttribute (element, "placement", "default;attached;detached;docked", (preview_mode == PlotPreview) ? 3 : 3, DL_INFO);
+	placement = (PreviewPlacement) xml->getMultiChoiceAttribute (element, "placement", "default;attached;detached;docked", 0, DL_INFO);
+	if (placement == DefaultPreview) placement = DockedPreview;
 	preview_active = xml->getBoolAttribute (element, "active", false, DL_INFO);
 	idprop = RObject::rQuote (QString ().sprintf ("%p", this));
 
 	// create and add property
 	addChild ("state", state = new RKComponentPropertyBool (this, true, preview_active, "active", "inactive"));
 	state->setInternal (true);	// restoring this does not make sense.
 	connect (state, SIGNAL (valueChanged(RKComponentPropertyBase*)), this, SLOT (changedState(RKComponentPropertyBase*)));
 
 	// create checkbox
 	QVBoxLayout *vbox = new QVBoxLayout (this);
 	vbox->setContentsMargins (0, 0, 0, 0);
 	toggle_preview_box = new QCheckBox (xml->i18nStringAttribute (element, "label", i18n ("Preview"), DL_INFO), this);
 	vbox->addWidget (toggle_preview_box);
 	toggle_preview_box->setChecked (preview_active);
 	connect (toggle_preview_box, SIGNAL (stateChanged(int)), this, SLOT (changedState(int)));
 
 	// status label
 	status_label = new QLabel (QString (), this);
 	status_label->setWordWrap (true);
 	vbox->addWidget (status_label);
 
 	// prepare placement
 	placement_command = ".rk.with.window.hints ({";
 	placement_end = "\n}, ";
 	if (placement == AttachedPreview) placement_end.append ("\"attached\"");
 	else if (placement == DetachedPreview) placement_end.append ("\"detached\"");
 	else placement_end.append ("\"\"");
 	placement_end.append (", " + RObject::rQuote (idprop) + ", style=\"preview\")");
 	if (placement == DockedPreview) {
 		RKStandardComponent *uicomp = topmostStandardComponent ();
 		if (uicomp) {
 			uicomp->addDockedPreview (state, toggle_preview_box->text (), idprop);
 
 			if (preview_mode == OutputPreview) {
 				RKGlobals::rInterface ()->issueCommand ("local ({\n"
 				    "outfile <- tempfile (fileext='html')\n"
 				    "rk.assign.preview.data(" + idprop + ", list (filename=outfile, on.delete=function (id) {\n"
 				    "	rk.flush.output (outfile, ask=FALSE)\n"
 				    "	unlink (outfile)\n"
 				    "}))\n"
 				    "oldfile <- rk.set.output.html.file (outfile, style='preview')  # for initialization\n"
 				    "rk.set.output.html.file (oldfile)\n"
 				    "})\n" + placement_command + "rk.show.html(rk.get.preview.data (" + idprop + ")$filename)" + placement_end, RCommand::Plugin | RCommand::Sync);
 			} else {
 				// For all others, create an empty data.frame as dummy. Even for custom docked previews it has the effect of initializing the preview area with _something_.
 				RKGlobals::rInterface ()->issueCommand ("local ({\nrk.assign.preview.data(" + idprop + ", data.frame ())\n})\n" + placement_command + "rk.edit(rkward::.rk.variables$.rk.preview.data[[" + idprop + "]])" + placement_end, RCommand::Plugin | RCommand::Sync);
 			}
 
 			// A bit of a hack: For now, in wizards, docked previews are always active, and control boxes are meaningless.
 			if (uicomp->isWizardish ()) {
 				hide ();
 				toggle_preview_box->setChecked (true);
 			}
 		}
 	}
 
 	// find and connect to code property of the parent
 	QString dummy;
 	RKComponentBase *cp = parentComponent ()->lookupComponent ("code", &dummy);
 	if (cp && dummy.isNull () && (cp->type () == PropertyCode)) {
 		code_property = static_cast<RKComponentPropertyCode *> (cp);
 		connect (code_property, SIGNAL (valueChanged(RKComponentPropertyBase*)), this, SLOT (changedCode(RKComponentPropertyBase*)));
 	} else {
 		RK_DEBUG (PLUGIN, DL_WARNING, "Could not find code property in preview box (remainder: %s)", dummy.toLatin1().data ());
 		code_property = 0;
 	}
 
 	// initialize
 	update_timer = new QTimer (this);
 	update_timer->setSingleShot (true);
 	connect (update_timer, SIGNAL (timeout()), this, SLOT (tryPreviewNow()));
 	updating = false;
 	changedState (0);
 }
 
 RKPreviewBox::~RKPreviewBox () {
 	RK_TRACE (PLUGIN);
 
 	killPreview (true);
 }
 
 QVariant RKPreviewBox::value(const QString& modifier) {
 	if (modifier == "id") {
 		return idprop;
 	}
 	return (state->value (modifier));
 }
 
 
 void RKPreviewBox::changedState (RKComponentPropertyBase *) {
 	RK_TRACE (PLUGIN);
 
 	if (updating) return;
 	updating = true;
 	toggle_preview_box->setChecked (state->boolValue ());
 	updating = false;
 
 	tryPreview ();
 	changed ();
 }
 
 void RKPreviewBox::changedCode (RKComponentPropertyBase *) {
 	RK_TRACE (PLUGIN);
 
 	tryPreview ();
 }
 
 void RKPreviewBox::changedState (int) {
 	RK_TRACE (PLUGIN);
 
 	state->setBoolValue (toggle_preview_box->isChecked ());
 }
 
 void RKPreviewBox::tryPreview () {
 	RK_TRACE (PLUGIN);
 
 	if (isEnabled () && toggle_preview_box->isChecked ()) update_timer->start (10);
 	else killPreview ();
 
 	updateStatusLabel ();
 }
 
 void RKPreviewBox::tryPreviewNow () {
 	RK_TRACE (PLUGIN);
 
 	if (!code_property) return;
 	ComponentStatus s = parentComponent ()->recursiveStatus ();
 	if (s != Satisfied) {
 		if (s == Processing) tryPreview ();
 		else {
 			setStatusMessage (i18n ("Preview not (currently) possible"));
 		}
 		return;
 	}
 
 	if (!prior_preview_done) {		// if the last plot is not done, yet, wait before starting the next.
 		new_preview_pending = true;
 		updateStatusLabel ();
 		return;
 	}
 
 	preview_active = true;
 
 	setStatusMessage (i18n ("Preview updating"));
 	if (preview_mode == PlotPreview) {
 		RKGlobals::rInterface ()->issueCommand (placement_command + ".rk.startPreviewDevice (" + idprop + ')' + placement_end, RCommand::Plugin | RCommand::Sync, QString ());
 		// creating window generates warnings, sometimes. Don't make those part of the warnings shown for the preview -> separate command for the actual plot.
 		RKGlobals::rInterface ()->issueCommand ("local({\n" + code_property->preview () + "})\n", RCommand::Plugin | RCommand::Sync, QString (), this, DO_PREVIEW);
 	} else if (preview_mode == DataPreview) {
 		RKGlobals::rInterface ()->issueCommand ("local({try({\n" + code_property->preview () + "\n})\nif(!exists(\"preview_data\",inherits=FALSE)) preview_data <- data.frame ('ERROR')\nrk.assign.preview.data(" + idprop + ", preview_data)\n})\n" + placement_command + "rk.edit(rkward::.rk.variables$.rk.preview.data[[" + idprop + "]])" + placement_end, RCommand::Plugin | RCommand::Sync, QString (), this, DO_PREVIEW);
 	} else if (preview_mode == OutputPreview) {
 		RKGlobals::rInterface ()->issueCommand (placement_command + "local({\n"
 		    "	oldfile <- rk.set.output.html.file(rk.get.preview.data (" + idprop + ")$filename, style='preview')\n"
 		    "	rk.flush.output(ask=FALSE, style='preview')\n"
 		    "	local({try({\n" + code_property->preview () + "\n})})\n"  // nested local to make sure "oldfile" is not overwritten.
 		    "	rk.set.output.html.file(oldfile)\n})\n"
 		    "rk.show.html(rk.get.preview.data (" + idprop + ")$filename)" + placement_end, RCommand::Plugin | RCommand::Sync, QString (), this, DO_PREVIEW);
 	} else {
 		RKGlobals::rInterface ()->issueCommand ("local({\n" + placement_command + code_property->preview () + placement_end + "})\n", RCommand::Plugin | RCommand::Sync, QString (), this, DO_PREVIEW);
 	}
 
 	prior_preview_done = false;
 	new_preview_pending = false;
 
 	updateStatusLabel ();
 }
 
 void RKPreviewBox::setStatusMessage(const QString& status) {
 	RK_TRACE (PLUGIN);
 
 	RKMDIWindow *window = RKWorkplace::mainWorkplace ()->getNamedWindow (idprop);
 	if (!window) return;
 	window->setStatusMessage (status);
 }
 
 void RKPreviewBox::killPreview (bool cleanup) {
 	RK_TRACE (PLUGIN);
 
 	if (!preview_active) return;
 	preview_active = false;
 
 	if (cleanup) {
 		QString command;
 		if (preview_mode == PlotPreview) command = ".rk.killPreviewDevice (" + idprop + ')';
 		else command = "rk.discard.preview.data (" + idprop + ')';
 		RKGlobals::rInterface ()->issueCommand (command, RCommand::Plugin | RCommand::Sync);
 	}
 	if (placement != DockedPreview) {
 		RKMDIWindow *window =  RKWorkplace::mainWorkplace ()->getNamedWindow (idprop);
 		if (window) window->deleteLater ();
 	}
 
 	prior_preview_done = true;
 	new_preview_pending = false;
 }
 
 void RKPreviewBox::rCommandDone (RCommand *command) {
 	RK_TRACE (PLUGIN);
 
 	prior_preview_done = true;
 	if (new_preview_pending) tryPreview ();
 
 	QString warnings = command->warnings () + command->error ();
 	if (!warnings.isEmpty ()) warnings = QString ("<b>%1</b>\n<pre>%2</pre>").arg (i18n ("Warnings or Errors:")).arg (Qt::escape (warnings));
 	setStatusMessage (warnings);
 
 	updateStatusLabel ();
 }
 
 void RKPreviewBox::updateStatusLabel () {
 	RK_TRACE (PLUGIN);
 
 	if (!toggle_preview_box->isChecked ()) {
 		status_label->setText (i18n ("Preview disabled"));
 	} else {
 		if (parentComponent ()->isSatisfied ()) {
 			if (prior_preview_done && (!new_preview_pending)) {
 				status_label->setText (i18n ("Preview up to date"));
 			} else {
 				status_label->setText (i18n ("Preview updating"));
 			}
 		} else {
 			status_label->setText (i18n ("Preview not (yet) possible"));
 		}
 	}
 }
 
 #include "rkpreviewbox.moc"