Index: src/documentation/userinterfaces/commandline.dox
===================================================================
--- src/documentation/userinterfaces/commandline.dox	(revision 415ddd8a44847064389eb3783769c8531725615c)
+++ src/documentation/userinterfaces/commandline.dox	(revision caece420aa82700e7677c24d798be09340eed2bd)
@@ -20,19 +20,20 @@
  * forward way.
  *
- * Commands are parsed via the CommandLineParser with uses boost::program_options
+ * Commands are parsed via the CommandLineParser which uses boost::program_options
  * to recognize the given options. ActionRegistry and OptionRegistry are used
- * to distinguish Option's from Action's. A specific type per option is expected
- * and the ValueStorage assures that only the correct type is parsed.
+ * to distinguish Option's from Action's. Each option has a specific type and a
+ * Validator ascertains that the value associated with this option and of this
+ * specific type matches certain criteria.
  *
  * So far the sequence of the Option's is not really important but for the
  * Action's the ordering counts: first come, first serve.
  *
- * Undoing is possible as well. But is so far only used in the regression test
- * to test its functionality. This will become more usefull when the
- * ActionHistory is stored to file and past session can be re-enacted by loading
- * simply it. Their undo would allow for traversing back in this history.
+ * Undoing is possible from the command-line as well. But is so far only used in
+ * the regression test to test its functionality. However, as the ActionHistory,
+ * or rather ActionQueue, can be saved as a session, this is useful as in a restored
+ * ActionHistory undo would allow for traversing back in this history.
  *
  *
- * \date 2011-10-31
+ * \date 2014-03-10
  *
  */
Index: src/documentation/userinterfaces/graphical.dox
===================================================================
--- src/documentation/userinterfaces/graphical.dox	(revision 415ddd8a44847064389eb3783769c8531725615c)
+++ src/documentation/userinterfaces/graphical.dox	(revision caece420aa82700e7677c24d798be09340eed2bd)
@@ -16,5 +16,5 @@
  * \page userinterfaces-graphical Graphical User Interface
  *
- * The GUI is based on Qt4. It used Qt3D for displaying the GlWorldView and
+ * The GUI is based on Qt4. It uses Qt3D for displaying the GlWorldView and
  * allowing for easy selecting of atoms and molecules.
  *
@@ -23,10 +23,12 @@
  * - a world view, implemented in GLWorldView, displaying atoms and bonds
  *   and allowing for selecting them.
- * - A list of all currently selected molecules.
- * - A list of all currently present molecules.
+ * - a tab widget on the right with hover info and a list of shapes.
+ * - a tab widget below the world view enlisting molecules, elements, fragments,
+ *   and homologies.
+ *
  *
  * \section userinterfaces-graphical-query Queries in the graphical interface.
  *
- * As all Action always instantiate a Dialog which behaves differently for
+ * As all Action's always instantiate a Dialog which behaves differently for
  * each of the three user interface, we give a brief description of what it
  * does here.
@@ -36,12 +38,13 @@
  * Eventually, this concatenated dialog is presented to the user -- it might
  * be empty though as well -- he enters all values and clicks accept (even
- * in case of an empty dialog). These values are passed via a Pipe mechanism
- * (this is a workaround as Qt's moc does not liked nested classes) to the
- * ValueStorage.
+ * in case of an empty dialog). These values are inspected with each Option's
+ * validator and only if all are true, accept is actually clickable. If not, at
+ * least one option is still invalid.
+ *
  *
  * \section userinterfaces-graphical-world_view How the World view works ...
  *
- * GLWorldView handles the Observer translation to Qt's own mechanism. Also, it
- * contains an instance of the GLWorldScene. This instance knows about all
+ * GLWorldView handles the Observer translation to Qt's own signal/slot mechanism. 
+ * Also, it contains an instance of the GLWorldScene. This instance knows all about
  * atoms and bonds present in this scene, i.e. it has lists on them and handles
  * adding and removing. Objects in this scene are GLMoleculeObject's which
@@ -53,5 +56,5 @@
  *
  *
- * \date 2012-01-05
+ * \date 2014-03-10
  *
  */
Index: src/documentation/userinterfaces/python.dox
===================================================================
--- src/documentation/userinterfaces/python.dox	(revision 415ddd8a44847064389eb3783769c8531725615c)
+++ src/documentation/userinterfaces/python.dox	(revision caece420aa82700e7677c24d798be09340eed2bd)
@@ -2,5 +2,5 @@
  * Project: MoleCuilder
  * Description: creates and alters molecular systems
- * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Copyright (C)  2013 Frederik Heber. All rights reserved.
  * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
  */
@@ -22,9 +22,10 @@
  *  This is done in \b src/Python/PythonScripting.cpp.
  *
- *  There again some preprocessor magic is happening. One the one hand we
- *  need GlobalListOfActions.hpp to have a list of all actions available.
- *  Second, in AllActionPython.hpp we define export functions for every
- *  Action (in essence we use the COMMAND function, see Action_impl_pre.hpp,
- *  which makes an Action usable internally as a normal function).
+ *  There again some preprocessor magic is happening, very similar to constructs
+ *  we used for the Action's. One the one hand we need GlobalListOfActions.hpp to 
+ *  have a list of all actions available. Second, in AllActionPython.hpp we define
+ *  export functions for every Action (in essence we use the COMMAND function, see 
+ *  Action_impl_pre.hpp, which makes an Action usable internally as a normal 
+ *  function).
  *
  *  Then, at the beginning of the BOOST_PYTHON_MODULE declaration we initialize
@@ -48,6 +49,12 @@
  *  \endcode
  *  which loads a file \b test.xyz into the (internal) World, selects the first
- *  atom and removes it. Notice \b mol.wait() at the end. This might be necessary
- *  as actions are executed in a different thread than the python script itself.
+ *  atom and removes it.
+ *
+ *  \subsection userinterfaces-python-first-test-wait Wait may be important ...
+ *
+ *  \note Notice \b mol.wait() at the end. This might be necessary as actions are 
+ *  executed in a different thread than the python script itself. This is only
+ *  enabled when configure is called with \b enable-action-thread.
+ *
  *  Hence, if you require values from molecuilder you have to make sure that
  *  all your actions have been processed by this second thread. That's what
@@ -82,5 +89,5 @@
  *
  *  If in the current directory a file \b molecuilder.py is found, the contents
- *  is executed as a regular python script.
+ *  is executed as a regular python script prior to any other Action's.
  *
  *  \note Each commands needs to be taken from a molecule called \a pyMoleCuilder.
@@ -141,23 +148,7 @@
  *  gives you the docu string on WorldInputAction.
  *
- * \subsection userinterfaces-python-notes-wait Waiting for the action queue
- *
- * Note again that actions are executed in a different thread as the python
- * script. Hence, we require synchronization at certain intervals where you
- * require molecuilder to be up to speed. All commands you executed such
- * as
- * \code
- * import pyMoleCuilder as mol
- * mol.WorldInput("foo.xyz")
- * mol.wait()
- * \endcode
- * just queue this specific input action but not execute it right away. That's
- * left to the other thread. Hence, you need to wait() before:
- * -# you access mol.get...() functions as these are not actions themselves.
- * -# you need to have files written by molecuilder to be parsed in the python
- *    script.
  *
  *
- * \date 2013-09-28
+ * \date 2014-03-10
  *
  */
Index: src/documentation/userinterfaces/textmenu.dox
===================================================================
--- src/documentation/userinterfaces/textmenu.dox	(revision 415ddd8a44847064389eb3783769c8531725615c)
+++ src/documentation/userinterfaces/textmenu.dox	(revision caece420aa82700e7677c24d798be09340eed2bd)
@@ -3,4 +3,5 @@
  * Description: creates and alters molecular systems
  * Copyright (C)  2010 University of Bonn. All rights reserved.
+ * Copyright (C)  2014 Frederik Heber. All rights reserved.
  * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
  */
@@ -16,17 +17,17 @@
  * \page userinterfaces-textmenu Text Menu Interface
  *
- *  The textmenu mimicks the graphical interface in having the very same menu
- *  with actions at the same positions. Only visual output can only be obtained
- *  by saving the world at intervals and inspecting the outcome. This is a sort
- *  of lowman's way to a graphical interface but can be done via a remote
- *  machine if its filesystem is mountable.
+ * The textmenu mimicks the graphical interface in having the very same menu
+ * with actions at the same positions. Only visual output can only be obtained
+ * by saving the world at intervals and inspecting the outcome via another program.
+ * This is a sort of layman's way to a graphical interface but can be done via a 
+ * remote machine if its filesystem is mountable.
  *
- *  \note The textmenu interface is the least maintained part of the user
- *  interfaces, so be cautious in using it. However, it also has the smallest
- *  impact in terms of code lines. In effect it may work just as well as the
- *  others.
+ * \note The textmenu interface is the least maintained part of the user
+ * interfaces, so be cautious in using it. However, it also has the smallest
+ * impact in terms of code lines. In effect it may work just as well as the
+ * others.
  *
  *
- *  \date 2011-10-31
+ * \date 2014-03-10
  *
  */
