Changeset e4afb4 for src/UIElements/Dialog.hpp

Timestamp:

Oct 30, 2010, 8:42:44 PM (15 years ago)

Author:

Frederik Heber <heber@…>

Branches:

Action_Thermostats, Add_AtomRandomPerturbation, Add_FitFragmentPartialChargesAction, Add_RotateAroundBondAction, Add_SelectAtomByNameAction, Added_ParseSaveFragmentResults, AddingActions_SaveParseParticleParameters, Adding_Graph_to_ChangeBondActions, Adding_MD_integration_tests, Adding_ParticleName_to_Atom, Adding_StructOpt_integration_tests, AtomFragments, Automaking_mpqc_open, AutomationFragmentation_failures, Candidate_v1.5.4, Candidate_v1.6.0, Candidate_v1.6.1, ChangeBugEmailaddress, ChangingTestPorts, ChemicalSpaceEvaluator, CombiningParticlePotentialParsing, Combining_Subpackages, Debian_Package_split, Debian_package_split_molecuildergui_only, Disabling_MemDebug, Docu_Python_wait, EmpiricalPotential_contain_HomologyGraph, EmpiricalPotential_contain_HomologyGraph_documentation, Enable_parallel_make_install, Enhance_userguide, Enhanced_StructuralOptimization, Enhanced_StructuralOptimization_continued, Example_ManyWaysToTranslateAtom, Exclude_Hydrogens_annealWithBondGraph, FitPartialCharges_GlobalError, Fix_BoundInBox_CenterInBox_MoleculeActions, Fix_ChargeSampling_PBC, Fix_ChronosMutex, Fix_FitPartialCharges, Fix_FitPotential_needs_atomicnumbers, Fix_ForceAnnealing, Fix_IndependentFragmentGrids, Fix_ParseParticles, Fix_ParseParticles_split_forward_backward_Actions, Fix_PopActions, Fix_QtFragmentList_sorted_selection, Fix_Restrictedkeyset_FragmentMolecule, Fix_StatusMsg, Fix_StepWorldTime_single_argument, Fix_Verbose_Codepatterns, Fix_fitting_potentials, Fixes, ForceAnnealing_goodresults, ForceAnnealing_oldresults, ForceAnnealing_tocheck, ForceAnnealing_with_BondGraph, ForceAnnealing_with_BondGraph_continued, ForceAnnealing_with_BondGraph_continued_betteresults, ForceAnnealing_with_BondGraph_contraction-expansion, FragmentAction_writes_AtomFragments, FragmentMolecule_checks_bonddegrees, GeometryObjects, Gui_Fixes, Gui_displays_atomic_force_velocity, ImplicitCharges, IndependentFragmentGrids, IndependentFragmentGrids_IndividualZeroInstances, IndependentFragmentGrids_IntegrationTest, IndependentFragmentGrids_Sole_NN_Calculation, JobMarket_RobustOnKillsSegFaults, JobMarket_StableWorkerPool, JobMarket_unresolvable_hostname_fix, MoreRobust_FragmentAutomation, ODR_violation_mpqc_open, PartialCharges_OrthogonalSummation, PdbParser_setsAtomName, PythonUI_with_named_parameters, QtGui_reactivate_TimeChanged_changes, Recreated_GuiChecks, Rewrite_FitPartialCharges, RotateToPrincipalAxisSystem_UndoRedo, SaturateAtoms_findBestMatching, SaturateAtoms_singleDegree, StoppableMakroAction, Subpackage_CodePatterns, Subpackage_JobMarket, Subpackage_LinearAlgebra, Subpackage_levmar, Subpackage_mpqc_open, Subpackage_vmg, Switchable_LogView, ThirdParty_MPQC_rebuilt_buildsystem, TrajectoryDependenant_MaxOrder, TremoloParser_IncreasedPrecision, TremoloParser_MultipleTimesteps, TremoloParser_setsAtomName, Ubuntu_1604_changes, stable

Children:

76cec6, c38826

Parents:

23359f

git-author:

Frederik Heber <heber@…> (10/30/10 19:55:54)

git-committer:

Frederik Heber <heber@…> (10/30/10 20:42:44)

Message:

Huge refactoring: Introduction of Traits to Actions.

This change is really big but the introduction of the Trait concept (at least
in its current light form) is so fundamental that lots of pieces had to be
changed in order to get everything working.

The main point why it was necessary to add these traits in the first place was
to comfortably allow for adding extension of Actions information-wise, i.e.
with stuff that is only important for the QtUI, such as icons, or tooltips, ...
This extra information should not be stored with Action itself, as it has
nothing to do with the workings of the Action. And neither should it get
stored with some blown-out-of-proportions MapOfActions class ...

The gist of the change is as follows:

• OptionTrait contains the token, description, shortform and type of an option, such as ("position", "position in space, none, typeid(Vector)).
• ActionTrait is the derived form for actions where additionally MenuPosition and MenuName are stored (and probably more to come for the GUI), also we have a set of OptionTrait instances, one for each option of the Action.
• Action then contains this ActionTrait, specialized for each Action.
• the preprocessor macros have been enhanced to gather all this information from the .def files.
• MapOfActions is gone. Completely. Most of its use was to store this extra information and the ValueStorage part now is just in class ValueStorage.
• ValueStorage is no more an interface to MapOfActions but as the name says a (type-safe) ValueStorage.

Listing the (remaining) changes in alphabetical order of the class:

• Action
  • member value ::name dropped, ::getName() uses ActionTraits::getName()
  • new define NODEFAULT which is used in paramdefaults in .def files
  • all derived actions classes such as Process, Calculations, MakroAction,... have been adapated to use the ActionTrait concept as well.

• ActionHistory
  • extraced RedoAction and UndoAction, shifted implementation into their own object files and they use .def files as well (i.e. streamlined with method used for other actions)

• CommandLineParser
  • CommandLineParser goes through ActionRegistry to get arguments and types to add
  • we use TypeEnumContainer which before was present in MapOfActions, as CommandLineParser::AddOptionsToParser() needs enums in its switch statement, we can't switch on types and types are not known until run-time. Hence, templates won't do either.
  • ShortFormMap is created here now (and used here only)
  • File was moved over to UIElements/CommandLineUI.

• MenuDescription
  • contain information on Menus such as name, ...
  • new unit test checks for consistency

• molecule
  • const member functions: Copy(), Output() and OutputBonds()

• OptionRegistry
  • new registry class for options only
  • we want the same type throughout the code for each token, e.g. "position"
  • the registry containts checks for consistency

• OptionTrait
  • default values are specified in paramdefaults, none are given by NODEFAULT
  • introduced default for translate-atoms, point-correlation, pair-correlation

• Registry pattern
  • new unit test, but only sceleton code so far

• ...Query, also ...Pipe
  • atoms, molecule and elements are now all const
  • also ValueStorage's signatures all have const therein

• ValueStorage
  • set/queryCurrentValue from MapOfActions
  • at times VectorValue has been in .def files where Vector was in the signature. This is cleared. Such stuff is only present for e.g. BoxVector being queried as a Vector. But this is a feature and intended.

• World
  • most of the (un)selection functions now work on const atoms and molecules
  • in one case we need a const_cast to remove this, but this is intentional, as the vector of selected atoms stores non-const pointers and this is ok.

There is only one test which had to be changed slightly because a specific
option token as "position" must now have the same type everywhere, e.g. always
Vector.

• TESTFIX: Simple_configuration/2: --position -> --domain-position (and associated to BoxVector)

File:

• src/UIElements/Dialog.hpp (modified) (5 diffs)

src/UIElements/Dialog.hpp

@@ -33 +33 @@
  * string, but also advanced types such as element, molecule or Vector. There
  * is also an empty query for displaying text.
+ *
+ * Note that the templatization of Dialog::query() allows for easy implementation
+ * of new types that correspond to/are derived from old ones.
+ *
+ * <H3>How do Dialogs operate?</H3>
+ *
+ * Dialogs are initiated by Action::FillDialog() function calls. Within Action::Call()
+ * a dialog is created and passed on to FillDialog(), which is specialized in each
+ * specific Action to ask for the specific parameter it needs.
+ *
+ * Dialogs are derived for each of the UI types
+ *  -# CommandLineDialog
+ *  -# QtDialog
+ *  -# TextDialog
+ *
+ * This "asking" for parameters is done via the Query class.  There are four types
+ * of Query types:
+ *  -# Query, members in class Dialog
+ *  -# CommandLineQuery, members in class CommandLineDialog
+ *  -# QtQuery, members in class QtDialog
+ *  -# TextQuery, members in class TextDialog
+ * Each embodies a certain way of asking the user for the specific type of parameter
+ * needed, e.g. a file via the TextMenu interface would be done in member functions of
+ * TextDialog::FileTextQuery.
+ *
+ *
+ * Generally, the sequence of events is as follows:
+ *  -# Action::fillDialog() calls upon Dialog::query<T> for some type T, let's say T
+ *     stands for double
+ *  -# Dialog::query<double> call a function queryDouble()
+ *  -# depending on the currently used UIFactory, the Dialog above is actually either
+ *     of the three specialized types, let's say CommandLine. And we see that within
+ *     CommandLineDialog we have the respective method ueryDouble() that registers
+ *     a new instance of the class CommandLineDialog::DoubleCommandLineQuery.
+ *  -# The Query's are first registered, as multiple parameters may be needed for
+ *     a single Action and we don't want the popping up of a dialog window for each
+ *     alone. Rather, we want to merge the Query's into a single Dialog. Therefore,
+ *     they are first registered and then executed in sequence. This is done in
+ *     Dialog::display(), i.e. when the dialog is finally shown to the user.
+ *  -# Then each of the registered Query's, here our CommandLineDialog::
+ *     DoubleCommandLineQuery, constructor is called.
+ *     -# This will call the constructor of its base class, where the actual value
+ *        is stored and later stored into the ValueStorage class by
+ *        Dialog::Query::setResult().
+ *     -# Also, e.g. for the Qt interface, the buttons, labels and so forth are
+ *        created and added to the dialog.
+ *  -# Now the users enters information for each UI something different happens:
+ *    -# CommandLine: The actual value retrieval is done by the CommandLineParser and
+ *       the boost::program_options library, the value is stored therein for the moment.
+ *       (see here: http://www.boost.org/doc/libs/1_44_0/doc/html/program_options/)
+ *    -# TextMenu: The value is requested via std::cin from the user.
+ *    -# QtMenu: The users enters the value in a Dialog. Due to Qt necessities a
+ *       Pipe class obtains the value from the Dialog with Qt's signal/slot mechanism
+ *       and put it into Dialog::...Query value.
+ *  -# in our case DoubleCommandLineQuery::handle() will be called. The value is
+ *     retrieved and put into Dialog::DoubleQuery::tmp
+ *  -# Finally, for each Query, also Dialog::DoubleQuery, setResult() is called which
+ *     puts the value as a string into the ValueStorage under a given token that is
+ *     associated with a type (and thereby we assure type-safety).
+ *
+ * <H3>Regarding derived types of types with already present queries</H3>
+ *
+ * Example: We have got a derived Vector class, called BoxVector, that is by any means
+ * a Vector but with one difference: it is always bound to lie within the current domain.
+ * With regards to type-casting it to and from a string however, nothing is different
+ * between Vector and BoxVector.
+ *
+ * So, do we need a new Query for this?
+ * No.
+ *
+ * We just have to do this:
+ *  -# add a specialization of Dialog::query<BoxVector> where queryVector()is used.
+ *     @code
+ *     template <> void Dialog::query<BoxVector>(const char *token, std::string description) {
+ *        queryVector(token, false, description);
+ *     }
+ *     @endcode
+ *  -# make sure that
+ *     -# ValueStorage::setCurrentValue() the specialization for class Vector has an
+ *     if case also for BoxVector and does something appropriate.
+ *     -# ValueStorage::queryCurrentValue() has another specialization doing the same
+ *     as for Vector but for BoxVector in its signature.
+ *
+ * And that's all.
+ *
+ *
+ * <H3>Adding new queries</H3>
+ *
+ * Check first whether you really need a new query or whether we can derive it and re-use
+ * one of the present ones.
+ *
+ * Due to the three present UI interfaces we have to add a specific Query for each, here
+ * is a list:
+ *   -# add ValueStorage::setCurrentValue() and ValueStorage::queryCurrentValue() for
+ *      both types
+ *   -# add Dialog::query...()
+ *   -# add Dialog::query<>() specialization calling the above function
+ *   -# add CommandLineDialog::query...(), TextDialog::query...(), and QtDialog::query...(),
+ *      i.e. for each of the three interface
+ *   -# add Dialog::...Query class with tmp value of desired type
+ *   -# add CommandLineDialog::...Query, TextDialog::...Query, QtDialog::...Query
+ *   -# you probably also need a QtDialog::...QueryPipe() to handle the signal/slot stuff,
+ *      Qt's moc does not like nested classes. Hence, this has to go extra.
+ *
  */
 class Dialog
@@ -210 +314 @@
     virtual void setResult();
   protected:
-    molecule *tmp;
+    const molecule *tmp;
   };
 
@@ -220 +324 @@
     virtual void setResult();
   protected:
-    molecule * temp;
-    std::vector<molecule *> tmp;
+    const molecule * temp;
+    std::vector<const molecule *> tmp;
   };
 
@@ -231 +335 @@
     virtual void setResult();
   protected:
-    atom *tmp;
+    const atom *tmp;
   };
 
@@ -241 +345 @@
     virtual void setResult();
   protected:
-    atom *temp;
-    std::vector<atom *> tmp;
+    const atom *temp;
+    std::vector<const atom *> tmp;
   };