Index: src/Actions/Action.hpp
===================================================================
--- src/Actions/Action.hpp	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/Actions/Action.hpp	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -36,9 +36,42 @@
 namespace MoleCuilder {
 
-/**
- * Base class for all actions.
+/** Actions are Command patterns to allow for undoing and redoing.
+ *
+ * Each specific Action derives from this class to implement a certain functionality.
  *
  * Actions describe something that has to be done.
- * Actions can be passed around, stored, performed and undone (Command-Pattern).
+ * Actions can be passed around, stored, performed and undone (Command-Pattern:
+ * http://en.wikipedia.org/wiki/Command_pattern).
+ *
+ * Unique to each Action is its ActionTrait, i.e. the options it requires
+ * to perform a certain function. E.g. in order to execute a "add atom" Action
+ * we need to know a position and an element. These options have certain
+ * properties, see \ref OptionTrait and \ref ActionTrait wherein these are stored.
+ * Essentially, each option is stored as an \ref OptionTrait instance and
+ * contains the token, default value, a description, the type, ...
+ *
+ * ActionTrait itself is also an OptionTrait because the command token may actually
+ * coincide with an option-token. E.g. this allows "...--add-atom 3" to mean
+ * both execute the action under token "add-atom" and that the option "add-atom"
+ * (the new atom's \ref element number) should contain 3.
+ *
+ * \ref ActionTrait contains a map of all associated options. With this in the cstor
+ * we register not only the Action with the \ref ActionRegistry but also each of
+ * its \link options OptionTrait \endlink with the \ref OptionRegistry.
+ *
+ * The token of the option is unique, but two Action's may share the same token if:
+ * -# they have the same default value
+ * -# they have the same type
+ *
+ * This requirement is easy because if you need to store some option of another
+ * type, simply think of a new suitable name for it.
+ *
+ * The actual value, i.e. "3" in the "add-atom" example, is taken from the
+ * ValueStorage, see \ref Dialog for how this is possible.
+ *
+ * \note There is a unit test that checks on the consistency of all registered
+ * options, also in "--enable-debug"-mode assertions will check that an option
+ * has not been registered before under another type.
+ *
  */
 class Action
Index: src/Actions/ActionRegistry.hpp
===================================================================
--- src/Actions/ActionRegistry.hpp	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/Actions/ActionRegistry.hpp	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -30,4 +30,11 @@
  * It is a singleton and can be called from anywhere.
  *
+ * ActionRegistry::fillRegistry() is the essential function, called in the cstor,
+ * where all the prototypical Action's are instantiated. To this end, we sadly
+ * require a global list of all present actions (\note there is a regression test
+ * check on its completeness). We include \ref GlobalListOfActionsh.hpp where a
+ * boost::preprocessor sequence is contained that is then used to install each
+ * of the Action's in the registry.
+ *
  */
 class ActionRegistry : public Singleton<ActionRegistry>, public Registry<Action>
Index: src/Actions/ValueStorage.hpp
===================================================================
--- src/Actions/ValueStorage.hpp	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/Actions/ValueStorage.hpp	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -84,10 +84,27 @@
 #include "CodePatterns/Singleton.hpp"
 
-/** ValueStorage serves as a mediator to MapOfActions.
+/** ValueStorage is a container for any type of value.
+ *
  * This is needed to relax inter-dependencies between the Queries and the Actions.
- * I.e. this is the interface implemented in MapOfActions which both can safely rely on
- * to store&retrieve/exchange values.
- *
- * \section ValueStorage ValueStorage howto
+ *
+ * The ValueStorage is necessary because we do not a-priori know about the
+ * type of a value as given by the user. The type is handled via RTTI (run-time
+ * type information), and the value is cast to string stored under a specific
+ * token in a map inside this class.
+ *
+ * Not any value can be stored in this container. We rely on OptionRegistry to allow
+ * only tokens whose type has been defined beforehand. I.e. for each option we
+ * require a specific and unique type.
+ *
+ * Then, there are three types of functions:
+ * -# queryCurrentValue: request a value under a specific token
+ * -# setCurrentValue: set/enter a value under a specific token
+ * -# isCurrentValuePresent: ask whether a value under a specific token is contained
+ *
+ * For the first two we have templated version and a number of specialized ones to
+ * deal with some types specific to this code: \ref atom, \ref Box, \ref element,
+ * \ref molecule, ...
+ *
+ * \section ValueStorage-extend ValueStorage extension howto
  *
  * If you ever need to add a particular class to the ValueStorage, do as follows:
@@ -98,4 +115,10 @@
  *    class' members to a stringstream or use an already implemented operator<<
  *    or operator<<, respectively.
+ *
+ * \section ValueStorage-further-info Further information
+ *
+ * If you want to know in detail how this all works with the options, where they
+ * come from and how values end up in the ValueStorage, then look at \ref  actions
+ * and \ref  userinterfaces.
  *
  */
Index: src/UIElements/Dialog.hpp
===================================================================
--- src/UIElements/Dialog.hpp	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/UIElements/Dialog.hpp	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -199,6 +199,20 @@
   /** Base class for all queries.
    *
+   * A query is request to the user for a value of a specific type.
+   * E.g. All \ref Action's need parameters to perform a specific function.
+   * These are obtained from the user at run-time via a Query regardless
+   * of the interface that the user is using.
    *
-   * <h1>How to add another query?</h1>
+   * A Query always contains a protected member variable of the specific type.
+   * For each type there is a derived class, e.g. for a boolean there is
+   * \ref BooleanQuery deriving from \ref Query. Each specific UI derives
+   * again from a specific Query, e.g. for the \link userinterfaces-textmenu
+   * textmenu \endlink we have \ref BooleanTextQuery that derives from
+   * \ref BooleanQuery. This derived class has to implement the Query::handle
+   * function that actually sets the protected member variable to something
+   * the user has entered. Also it implements Query::setResult that actually
+   * places the obtained value in the \ref ValueStorage.
+   *
+   * \section query-howto How to add another query?
    *
    * Let's say  we want to query for a type called \a Value.
Index: src/documentation/constructs/actions.dox
===================================================================
--- src/documentation/constructs/actions.dox	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/documentation/constructs/actions.dox	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -15,5 +15,6 @@
 /** \page actions Actions
  *
- *  Actions are Command patterns (http://en.wikipedia.org/wiki/Command_pattern)
+ *  \link MoleCuilder::Action Actions \endlink are Command patterns
+ *  (http://en.wikipedia.org/wiki/Command_pattern)
  *  to allow for undoing and redoing. Each specific Action derives from this
  *  class to implement a certain functionality. There is a lot of preprocessor
@@ -27,6 +28,6 @@
  *  such that an instance can be retrieved by knowing this token.
  *
- *  Each Action obtains its parameter from a central ValueStorage such that
- *  they are independent of where the parameter originated from: a command line
+ *  Each Action obtains its options from a central ValueStorage such that
+ *  they are independent of where the option originated from: a command line
  *  parameter, a value entered in a graphical dialog or given via the keyboard
  *  in a terminal. That's why each begins with a function call to
@@ -62,4 +63,10 @@
  * Have a look at \ref UndoRedoHelpers.hpp for some helper functions on this.
  *
+ * \section actions-further Further information
+ *
+ * If you want know:
+ * -# how the code knows about the valid tokens for actions and options and how
+ *    they are constructed, see \ref MoleCuilder::Action .
+ *
  *
  *  \date 2012-04-05
Index: src/documentation/constructs/constructs.dox
===================================================================
--- src/documentation/constructs/constructs.dox	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/documentation/constructs/constructs.dox	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -36,4 +36,5 @@
  *  \li \ref shapes
  *  \li \ref tesselation
+ *  \li \ref values
  *  \li \ref world
  *
Index: src/documentation/constructs/values.dox
===================================================================
--- src/documentation/constructs/values.dox	(revision b2c30277e29ff71804fcb5db963189440f56db52)
+++ src/documentation/constructs/values.dox	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -0,0 +1,70 @@
+/*
+ * Project: MoleCuilder
+ * Description: creates and alters molecular systems
+ * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
+ */
+
+/**
+ * \file values.dox
+ *
+ * Created on: Mar 16, 2012
+ *    Author: heber
+ */
+
+/**
+ * \page values Values from the user to the Action
+ *
+ * The way from a value to end up as a option value/parameter inside an
+ * \link MoleCuilder::Action Action \endlink ist rather complex. Hence,
+ * let us briefly sketch the complete path, ranging from the \link
+ * userinterfaces User Interface \endlink to the Action.
+ *
+ * \section value-from-ui From the user interface ...
+ *
+ * The user may enter a value either in ...
+ *  -# a command line option, e.g. ...--position "0,1,2" ...
+ *  -# a text interface, e.g. "Which position:" "0,1,2"
+ *  -# a GUI dialog: Placing "0,1,2" in some text box or alike.
+ *
+ * This is handled by a class derived from a \ref Dialog::Query and all queries
+ * of a specific Action are placed into a \ref Dialog. A \ref Dialog::Query
+ * may e.g. be \ref TextDialog::VectorTextQuery. This class is derived from
+ * \ref Dialog::VectorQuery which is derived from Query.
+ *
+ * The \ref Dialog::Query instance has a member Query::tmp which eventually
+ * contains the value of a specific type (here Vector) from the user.
+ * TextDialog::VectorTextQuery::handle() asks the user in some way for the value,
+ * Dialog::VectorQuery::setResult() places Dialog::VectorQuery::tmp into the
+ * \ref ValueStorage. This is done under a specific token which the Query
+ * knows via its cstor: Query::title.
+ *
+ * ValueStorage does not take any value but only those it knows and more
+ * specifically whose type it knows. I.e. for each option it has to know
+ * a token and a name. These are contained in instances of \ref OptionTrait.
+ * The list of these instances is contained in \ref ActionTrait which each
+ * specialized \link MoleCuilder::Action Action \endlink gets on construction.
+ * In Action's cstor these Trait's are registered with the \ref ActionRegistry
+ * and the \ref OptionRegistry.
+ *
+ * And the OptionRegistry is then the place where \ref ValueStorage checks
+ * whether token and type (the value) given to it are correct. This is required
+ * to ensure that only a specific type is associated with each token. If another
+ * type is needed simply think of a new token.
+ *
+ * \section value-from-action ... into the Action
+ *
+ * Now the value rests inside the ValueStorage as a string with a known type.
+ * Every \link MoleCuilder::Action Action \endlink in its Action::performCall()
+ * call Action::getParametersFromValueStorage() which fills an internal
+ * Action::params structure (that is constructed as most of the other stuff
+ * in an action via boost::preprocessor magic). This is then used by the
+ * Action to know that the token "position" with value "0,1,2" which the user
+ * supplied are meant to place a new atom at (0,1,2) (\ref AddAtomAction). It
+ * takes the value from AtomAddAction::params::position (all these information
+ * is stored in \ref AddAction.def).
+ *
+ *
+ * \date 2012-03-16
+ *
+ */
Index: src/documentation/userinterfaces/userinterfaces.dox
===================================================================
--- src/documentation/userinterfaces/userinterfaces.dox	(revision be21faee0c27bbf2439e848bacfe01d94e55d9e0)
+++ src/documentation/userinterfaces/userinterfaces.dox	(revision b2c30277e29ff71804fcb5db963189440f56db52)
@@ -36,6 +36,11 @@
  *  \section userinterfaces-query Making queries to the user
  *
- *  The passing of values from the user to the code is done via a Query class
- *  which each of the interfaces implements for each of the required types.
+ *  The passing of values from the user to the code is done via a \ref Dialog
+ *  class that contains a number of \ref Query instances.
+ *  Both Dialog and Query have to be implemented for each of the interfaces
+ *  for each of the required types.
+ *
+ *  See \ref Query to understand how a value from the user actually happens to
+ *  end up in the \ref ValueStorage for \ref Action's to find it.
  *
  *  \section userinterfaces-menu Menu structure
@@ -44,5 +49,5 @@
  *
  *
- * \date 2011-10-31
+ * \date 2012-03-16
  *
  */
