1 | /*
|
---|
2 | * Dialog.hpp
|
---|
3 | *
|
---|
4 | * Created on: Jan 5, 2010
|
---|
5 | * Author: crueger
|
---|
6 | */
|
---|
7 |
|
---|
8 | #ifndef DIALOG_HPP_
|
---|
9 | #define DIALOG_HPP_
|
---|
10 |
|
---|
11 | // include config.h
|
---|
12 | #ifdef HAVE_CONFIG_H
|
---|
13 | #include <config.h>
|
---|
14 | #endif
|
---|
15 |
|
---|
16 |
|
---|
17 | #include<string>
|
---|
18 | #include<list>
|
---|
19 | #include<vector>
|
---|
20 |
|
---|
21 | #include <boost/filesystem.hpp>
|
---|
22 | #include "LinearAlgebra/RealSpaceMatrix.hpp"
|
---|
23 | #include "LinearAlgebra/Vector.hpp"
|
---|
24 | #include "RandomNumbers/RandomNumberDistribution_Parameters.hpp"
|
---|
25 | #include "Parameters/Parameter.hpp"
|
---|
26 |
|
---|
27 | class atom;
|
---|
28 | class RealSpaceMatrix;
|
---|
29 | class element;
|
---|
30 | class molecule;
|
---|
31 |
|
---|
32 |
|
---|
33 | /** Dialog is one of the two main classes of the UIFactory base class.
|
---|
34 | *
|
---|
35 | * The Dialog is meant for asking the user for information needed to perform
|
---|
36 | * actions he desires, such as asking for a position in space or a length.
|
---|
37 | *
|
---|
38 | * For this purpose there is the base class Query and numerous specializations
|
---|
39 | * for each of the types to be asked. There are primitives integer, doubles and
|
---|
40 | * string, but also advanced types such as element, molecule or Vector. There
|
---|
41 | * is also an empty query for displaying text.
|
---|
42 | *
|
---|
43 | * Note that the templatization of Dialog::query() allows for easy implementation
|
---|
44 | * of new types that correspond to/are derived from old ones.
|
---|
45 | *
|
---|
46 | * <H3>How do Dialogs operate?</H3>
|
---|
47 | *
|
---|
48 | * Dialogs are initiated by Action::FillDialog() function calls. Within Action::Call()
|
---|
49 | * a dialog is created and passed on to FillDialog(), which is specialized in each
|
---|
50 | * specific Action to ask for the specific parameter it needs.
|
---|
51 | *
|
---|
52 | * Dialogs are derived for each of the UI types
|
---|
53 | * -# CommandLineDialog
|
---|
54 | * -# QtDialog
|
---|
55 | * -# TextDialog
|
---|
56 | *
|
---|
57 | * This "asking" for parameters is done via the Query class. There are four types
|
---|
58 | * of Query types:
|
---|
59 | * -# Query, members in class Dialog
|
---|
60 | * -# CommandLineQuery, members in class CommandLineDialog
|
---|
61 | * -# QtQuery, members in class QtDialog
|
---|
62 | * -# TextQuery, members in class TextDialog
|
---|
63 | * Each embodies a certain way of asking the user for the specific type of parameter
|
---|
64 | * needed, e.g. a file via the TextMenu interface would be done in member functions of
|
---|
65 | * TextDialog::FileTextQuery.
|
---|
66 | *
|
---|
67 | *
|
---|
68 | * Generally, the sequence of events is as follows:
|
---|
69 | * -# Action::fillDialog() calls upon Dialog::query<T> for some type T, let's say T
|
---|
70 | * stands for double
|
---|
71 | * -# Dialog::query<double> call a function queryDouble()
|
---|
72 | * -# depending on the currently used UIFactory, the Dialog above is actually either
|
---|
73 | * of the three specialized types, let's say CommandLine. And we see that within
|
---|
74 | * CommandLineDialog we have the respective method ueryDouble() that registers
|
---|
75 | * a new instance of the class CommandLineDialog::DoubleCommandLineQuery.
|
---|
76 | * -# The Query's are first registered, as multiple parameters may be needed for
|
---|
77 | * a single Action and we don't want the popping up of a dialog window for each
|
---|
78 | * alone. Rather, we want to merge the Query's into a single Dialog. Therefore,
|
---|
79 | * they are first registered and then executed in sequence. This is done in
|
---|
80 | * Dialog::display(), i.e. when the dialog is finally shown to the user.
|
---|
81 | * -# Then each of the registered Query's, here our CommandLineDialog::
|
---|
82 | * DoubleCommandLineQuery, constructor is called.
|
---|
83 | * -# This will call the constructor of its base class, where the actual value
|
---|
84 | * is stored and later stored into the ValueStorage class by
|
---|
85 | * Dialog::Query::setResult().
|
---|
86 | * -# Also, e.g. for the Qt interface, the buttons, labels and so forth are
|
---|
87 | * created and added to the dialog.
|
---|
88 | * -# Now the users enters information for each UI something different happens:
|
---|
89 | * -# CommandLine: The actual value retrieval is done by the CommandLineParser and
|
---|
90 | * the boost::program_options library, the value is stored therein for the moment.
|
---|
91 | * (see here: http://www.boost.org/doc/libs/1_44_0/doc/html/program_options/)
|
---|
92 | * -# TextMenu: The value is requested via std::cin from the user.
|
---|
93 | * -# QtMenu: The users enters the value in a Dialog. Due to Qt necessities a
|
---|
94 | * Pipe class obtains the value from the Dialog with Qt's signal/slot mechanism
|
---|
95 | * and put it into Dialog::...Query value.
|
---|
96 | * -# in our case DoubleCommandLineQuery::handle() will be called. The value is
|
---|
97 | * retrieved and put into Dialog::DoubleQuery::tmp
|
---|
98 | * -# Finally, for each Query, also Dialog::DoubleQuery, setResult() is called which
|
---|
99 | * puts the value as a string into the ValueStorage under a given token that is
|
---|
100 | * associated with a type (and thereby we assure type-safety).
|
---|
101 | *
|
---|
102 | * <H3>Regarding derived types of types with already present queries</H3>
|
---|
103 | *
|
---|
104 | * Example: We have got a derived Vector class, called BoxVector, that is by any means
|
---|
105 | * a Vector but with one difference: it is always bound to lie within the current domain.
|
---|
106 | * With regards to type-casting it to and from a string however, nothing is different
|
---|
107 | * between Vector and BoxVector.
|
---|
108 | *
|
---|
109 | * So, do we need a new Query for this?
|
---|
110 | * No.
|
---|
111 | *
|
---|
112 | * We just have to do this:
|
---|
113 | * -# add a specialization of Dialog::query<BoxVector> where queryVector()is used.
|
---|
114 | * @code
|
---|
115 | * template <> void Dialog::query<BoxVector>(const char *token, std::string description) {
|
---|
116 | * queryVector(token, false, description);
|
---|
117 | * }
|
---|
118 | * @endcode
|
---|
119 | * -# make sure that
|
---|
120 | * -# ValueStorage::setCurrentValue() the specialization for class Vector has an
|
---|
121 | * if case also for BoxVector and does something appropriate.
|
---|
122 | * -# ValueStorage::queryCurrentValue() has another specialization doing the same
|
---|
123 | * as for Vector but for BoxVector in its signature.
|
---|
124 | *
|
---|
125 | * And that's all.
|
---|
126 | *
|
---|
127 | *
|
---|
128 | * <H3>Adding new queries</H3>
|
---|
129 | *
|
---|
130 | * Check first whether you really need a new query or whether we can derive it and re-use
|
---|
131 | * one of the present ones.
|
---|
132 | *
|
---|
133 | * Due to the three present UI interfaces we have to add a specific Query for each, here
|
---|
134 | * is a list:
|
---|
135 | * -# add ValueStorage::setCurrentValue() and ValueStorage::queryCurrentValue() for
|
---|
136 | * both types
|
---|
137 | * -# add Dialog::query...()
|
---|
138 | * -# add Dialog::query<>() specialization calling the above function
|
---|
139 | * -# add CommandLineDialog::query...(), TextDialog::query...(), and QtDialog::query...(),
|
---|
140 | * i.e. for each of the three interface
|
---|
141 | * -# add empty definition DummyDialog::query...() to the stub for Action unittests in DummUI.hpp.
|
---|
142 | * -# add Dialog::...Query class with tmp value of desired type
|
---|
143 | * -# add CommandLineDialog::...Query, TextDialog::...Query, QtDialog::...Query
|
---|
144 | * -# you probably also need a QtDialog::...QueryPipe() to handle the signal/slot stuff,
|
---|
145 | * Qt's moc does not like nested classes. Hence, this has to go extra.
|
---|
146 | * -# TypeEnumContainer add new type to query
|
---|
147 | * -# CommandLineParser::AddOptionToParser() add new type to query
|
---|
148 | * -# CommandLineParser_valdiates.[ch]pp: If given above as a new type
|
---|
149 | * program_options::value, define and implement a validate() function here.
|
---|
150 | *
|
---|
151 | */
|
---|
152 | class Dialog
|
---|
153 | {
|
---|
154 | public:
|
---|
155 | Dialog();
|
---|
156 | virtual ~Dialog();
|
---|
157 |
|
---|
158 | template <class T> void query(Parameter<T> &, const char *, std::string = "");
|
---|
159 |
|
---|
160 | virtual void queryEmpty(const char *, std::string = "")=0;
|
---|
161 | virtual void queryBoolean(Parameter<bool> &, const char *, std::string = "")=0;
|
---|
162 | virtual void queryInt(Parameter<int> &, const char *, std::string = "")=0;
|
---|
163 | virtual void queryInts(Parameter<std::vector<int> > &, const char *, std::string = "")=0;
|
---|
164 | virtual void queryUnsignedInt(Parameter<unsigned int> &, const char *, std::string = "")=0;
|
---|
165 | virtual void queryUnsignedInts(Parameter<std::vector<unsigned int> > &, const char *, std::string = "")=0;
|
---|
166 | virtual void queryDouble(Parameter<double> &, const char*, std::string = "")=0;
|
---|
167 | virtual void queryDoubles(Parameter<std::vector<double> > &, const char*, std::string = "")=0;
|
---|
168 | virtual void queryString(Parameter<std::string> &, const char*, std::string = "")=0;
|
---|
169 | virtual void queryStrings(Parameter<std::vector<std::string> > &, const char*, std::string = "")=0;
|
---|
170 | virtual void queryAtom(Parameter<const atom *> &, const char*,std::string = "")=0;
|
---|
171 | virtual void queryAtoms(Parameter<std::vector<const atom *> > &, const char*,std::string = "")=0;
|
---|
172 | virtual void queryMolecule(Parameter<const molecule *> &, const char*, std::string = "")=0;
|
---|
173 | virtual void queryMolecules(Parameter<std::vector<const molecule *> > &, const char*, std::string = "")=0;
|
---|
174 | virtual void queryVector(Parameter<Vector> &, const char*, std::string = "")=0;
|
---|
175 | virtual void queryVectors(Parameter<std::vector<Vector> > &, const char*, std::string = "")=0;
|
---|
176 | virtual void queryRealSpaceMatrix(Parameter<RealSpaceMatrix> &, const char*, std::string = "")=0;
|
---|
177 | virtual void queryElement(Parameter<const element *> &, const char*, std::string = "")=0;
|
---|
178 | virtual void queryElements(Parameter<std::vector<const element *> > &, const char*, std::string = "")=0;
|
---|
179 | virtual void queryFile(Parameter<boost::filesystem::path> &, const char*, std::string = "")=0;
|
---|
180 | virtual void queryFiles(Parameter< std::vector<boost::filesystem::path> > &, const char*, std::string = "")=0;
|
---|
181 | virtual void queryRandomNumberDistribution_Parameters(Parameter<RandomNumberDistribution_Parameters> &, const char*, std::string = "")=0;
|
---|
182 |
|
---|
183 | virtual bool display();
|
---|
184 |
|
---|
185 | virtual void handleAll();
|
---|
186 | virtual bool checkAll();
|
---|
187 | virtual void setAll();
|
---|
188 |
|
---|
189 | virtual bool hasQueries();
|
---|
190 |
|
---|
191 | virtual void update(){}
|
---|
192 |
|
---|
193 | protected:
|
---|
194 | // methodology for handling queries
|
---|
195 | // all queries are stored and then performed at appropriate times
|
---|
196 |
|
---|
197 | //these queries can be handled by this dialog
|
---|
198 |
|
---|
199 | //TODO: Find a way to reduce complexity...
|
---|
200 | //needs O(N*M) query classes, where N is the number of query types and M is the number of GUIs
|
---|
201 | //usual approach for reducing inheritance complexity (strategy pattern) does not work,
|
---|
202 | //due to lack of common code for query types as well as GUI-Types (all subtypes differ a lot)
|
---|
203 |
|
---|
204 | /** Base class for all queries.
|
---|
205 | *
|
---|
206 | * A query is request to the user for a value of a specific type.
|
---|
207 | * E.g. All \ref Action's need parameters to perform a specific function.
|
---|
208 | * These are obtained from the user at run-time via a Query regardless
|
---|
209 | * of the interface that the user is using.
|
---|
210 | *
|
---|
211 | * A Query always contains a protected member variable of the specific type.
|
---|
212 | * For each type there is a derived class, e.g. for a boolean there is
|
---|
213 | * \ref BooleanQuery deriving from \ref Query. Each specific UI derives
|
---|
214 | * again from a specific Query, e.g. for the \link userinterfaces-textmenu
|
---|
215 | * textmenu \endlink we have \ref BooleanTextQuery that derives from
|
---|
216 | * \ref BooleanQuery. This derived class has to implement the Query::handle
|
---|
217 | * function that actually sets the protected member variable to something
|
---|
218 | * the user has entered. Also it implements Query::setResult that actually
|
---|
219 | * places the obtained value in the \ref ValueStorage.
|
---|
220 | *
|
---|
221 | * \section query-howto How to add another query?
|
---|
222 | *
|
---|
223 | * Let's say we want to query for a type called \a Value.
|
---|
224 | *
|
---|
225 | * Then, we do the following:
|
---|
226 | * -# Add a class ValueQuery inside class Dialog, the class contains
|
---|
227 | * -# constructor/destructor (latter virtual! because of derived class)
|
---|
228 | * -# virtual bool handle() and virtual void setResult()
|
---|
229 | * -# a protected member tmp of type Value (NOTE: herein the result is stored)
|
---|
230 | * -# if temporaries for conversion are needed put them in here
|
---|
231 | * -# add a function queryValue
|
---|
232 | * -# now, for each of the GUIs we basically have to repeat the above, i.e.
|
---|
233 | * add the class and the function that implement the virtual ones above.
|
---|
234 | * -# QT: an extra class called ValueQtQueryPipe that actually handles
|
---|
235 | * showing dialogs to obtain the value and placing it into the \a tmp
|
---|
236 | * variable (via a given pointer to it as reference). handle() will
|
---|
237 | * simply return true. This is needed because of a restriction of Qt4:
|
---|
238 | * its meta-object-compiler does not like nested classes.
|
---|
239 | * -# CommandLine: nothing special, handle() imports value from \a
|
---|
240 | * CommandLineParser and sets the tmp variable.
|
---|
241 | * -# Text: nothing special, handle() queries the user and sets the tmp
|
---|
242 | * variable
|
---|
243 | */
|
---|
244 | class Query {
|
---|
245 | friend class Dialog;
|
---|
246 | public:
|
---|
247 | Query(std::string _title, std::string _description = "");
|
---|
248 | virtual ~Query();
|
---|
249 | virtual bool handle()=0;
|
---|
250 | virtual bool isValid()=0;
|
---|
251 | virtual void setResult()=0;
|
---|
252 | protected:
|
---|
253 | const std::string getTitle() const;
|
---|
254 | const std::string getDescription() const;
|
---|
255 | private:
|
---|
256 | std::string title; //!< short title of the query
|
---|
257 | std::string description; //!< longer description for tooltips or for help
|
---|
258 | };
|
---|
259 |
|
---|
260 |
|
---|
261 | template<class T>
|
---|
262 | class TQuery : public Query {
|
---|
263 | public:
|
---|
264 | TQuery(Parameter<T> &_param, std::string title, std::string _description = "") :
|
---|
265 | Query(title, _description), param(_param) {}
|
---|
266 | virtual ~TQuery(){}
|
---|
267 | virtual bool handle()=0;
|
---|
268 | virtual bool isValid(){ return param.isValid(temp); }
|
---|
269 | virtual void setResult(){ param.set(temp); }
|
---|
270 | protected:
|
---|
271 | T temp;
|
---|
272 | Parameter<T> ¶m;
|
---|
273 | };
|
---|
274 |
|
---|
275 | // Empty Query is just meant for showing text, such as version, help, initial message or alike
|
---|
276 | class EmptyQuery : public Query {
|
---|
277 | public:
|
---|
278 | EmptyQuery(std::string title, std::string _description = "");
|
---|
279 | virtual ~EmptyQuery();
|
---|
280 | virtual bool handle()=0;
|
---|
281 | virtual bool isValid(){ return true; }
|
---|
282 | virtual void setResult();
|
---|
283 | };
|
---|
284 |
|
---|
285 | void registerQuery(Query* query);
|
---|
286 |
|
---|
287 | private:
|
---|
288 | std::list<Query*> queries;
|
---|
289 |
|
---|
290 | };
|
---|
291 |
|
---|
292 |
|
---|
293 | #endif /* DIALOG_HPP_ */
|
---|