Index: src/UIElements/Dialog.hpp
===================================================================
--- src/UIElements/Dialog.hpp	(revision 6ffc0b5857c2bdc65abf4dd377e4d6ab72c2dc7b)
+++ src/UIElements/Dialog.hpp	(revision 7ef5b9a28cc8e6a75e313d161b3e003834eae2a6)
@@ -197,9 +197,4 @@
   //these queries can be handled by this dialog
 
-  //TODO: Find a way to reduce complexity...
-  //needs O(N*M) query classes, where N is the number of query types and M is the number of GUIs
-  //usual approach for reducing inheritance complexity (strategy pattern) does not work,
-  //due to lack of common code for query types as well as GUI-Types (all subtypes differ a lot)
-
   /** Base class for all queries.
    *
@@ -209,13 +204,22 @@
    * of the interface that the user is using.
    *
-   * 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.
+   * A Query just has title and description and serves as the general interface
+   * to queries. TQuery is a templatization of the Query containing a protected
+   * member variable of the specific type and also a Parameter<> reference of
+   * the type that actually belongs to the Action that triggered/created the
+   * Query. handle() is UI-specific and sets the (temporary) member variable. 
+   * However, isValid() in TQuery checks via the Parameter<> reference whether
+   * the variable is valid with the given Validators and setResult() finally
+   * set the Parameter with the temporary variable.
+   *
+   * For each type there is a derived class per \b UI, e.g. for the
+   * \link userinterfaces-textmenu textmenu \endlink we have 
+   * \ref BooleanTextQuery that derives from \ref TQuery<bool>. This derived
+   * class has to implement the Query::handle() function that actually sets
+   * the protected member variable to something the user has entered. 
+   *
+   * Thanks to the templated TQuery this is a as simple as it can get. The
+   * handle() has to be UI-specific, hence has to be implemented once for
+   * every present UI. But all other code can be used for either of them.
    *
    * \section query-howto How to add another query?
@@ -224,17 +228,9 @@
    *
    * Then, we do the following:
-   *  -# Add a class ValueQuery inside class Dialog, the class contains
-   *    -# constructor/destructor (latter virtual! because of derived class)
-   *    -# virtual bool handle() and virtual void setResult()
-   *    -# a protected member tmp of type Value (NOTE: herein the result is stored)
-   *    -# if temporaries for conversion are needed put them in here
-   *  -# add a function queryValue
-   *  -# now, for each of the GUIs we basically have to repeat the above, i.e.
-   *     add the class and the function that implement the virtual ones above.
-   *    -# QT: an extra class called ValueQtQueryPipe that actually handles
-   *       showing dialogs to obtain the value and placing it into the \a tmp
-   *       variable (via a given pointer to it as reference). handle() will
-   *       simply return true. This is needed because of a restriction of Qt4:
-   *       its meta-object-compiler does not like nested classes.
+   *  -# add a virtual function queryValue inside class Dialog.
+   *  -# now, for each of the GUIs we basically have to add a sub-class for the
+   *     respective Query inside the derived Dialog that implements handle().
+   *    -# QT: typically we use a onUpdate() function here attached the Qt
+   *       signals and handle then just does nothing.
    *    -# CommandLine: nothing special, handle() imports value from \a
    *       CommandLineParser and sets the tmp variable.
Index: src/documentation/constructs/actions.dox
===================================================================
--- src/documentation/constructs/actions.dox	(revision 6ffc0b5857c2bdc65abf4dd377e4d6ab72c2dc7b)
+++ src/documentation/constructs/actions.dox	(revision 7ef5b9a28cc8e6a75e313d161b3e003834eae2a6)
@@ -53,6 +53,6 @@
  * has to be implemented in two more functions beside the "do".
  *
- * Note that undoing means to get every back to its original state and by whatever
- * means seem appropriate, e.g. just remvoing all inserted atoms.
+ * Note that undoing means to get everything back to its original state and by
+ * whatever means seem appropriate, e.g. just remvoing all inserted atoms.
  * To make this more elaborate it is usually very useful to store extra information
  * in the Action's state such that undo and redo can be accomplished more quickly.
@@ -70,5 +70,5 @@
  *
  *
- *  \date 2012-04-05
+ *  \date 2012-12-04
  *
  */
