[Qt-interest] Designing Qt applications

[Oliver.Knoll at comit.ch]

On 2010-08-24 Markus Markus Franke wrote:

> 
> Thanks for the detailed answer.
> 
> As I am writing my GUI code by hand and not using anything like Qt 
> Designer or Qt Quick I sometimes find it hard to identify the 
> borders/interfaces between the view and the controller.

I agree - in fact, a lot of Qt GUI widgets could considered to be both at the same time (View/Controller), for example the simple QSpinBox: it offers two up/down arrows which "control" the value. But if you take the "Controller" part to be a little bit more complex than just changing some values you could say the class which "implements" the GUI logic is the controller - and I still take it to the example of Qt Designer, but the same argument applies when you hand-code the GUI part (in a separate base class, or just in a separate "UI namespace", the approach which is taken when auto-generating code from the *.ui files).

So everything you design within Designer is eventually put into auto-generated code which is located in some Ui namespace. In your actual "dialog logic" class you simply call setupUi() (or similar, can't remember the exact name), typically in the c'tor of that class.

Then the rest deals with connecting to the signals the GUI elements emit and handle them. Or whenever the text changes in some text box you could connect to the "text changed" signal and apply some validation on it. Or depending on which widget has focus or the current values you would enable/disable certain widgets etc.

All that would be done in the "controller class".

But off course you can also "install" e.g. a QIntValidator in a QLineEdit widget, so it also becomes the "controller". So yes, the borders are somewhat not clearly visible, but that is not necessarily bad: input data and display thereof sometimes really goes hand in hand, and it does not always make sense to strictly separate those concerns!

For example the Oberon operating system (http://www.oberon.ethz.ch/) - at least in its original implementation - by design did not separate the View/Controller part, the display and handling logic (data input, validation, enabling/disabling certain GUI elements, ...) was usually implemented in one "module" (or class). In some (old) whitepaper they talk about "generalised MVC Scheme": http://www-old.oberon.ethz.ch/white.htm


The Data part however is easily separateable: in any model class there should not be a single #include from the QtGui module (no widgets!). In my case the model classes are simple plain C++ classes that use Qt datatypes (such as QVariant, QString, QMap, ...) and simply emit signals as soon as the data changes. The "Controller" then picks up these signals and updates the View (the generated code) accordingly by either setting the values itself or simply connecting the signal directly to the corresponding widget (when no validation or extra action is needed).


As for "Design Patterns" books: nomen est omen: "Design Patterns" by Gamma, Helm, Johnson, Vlissides - Addison-Wesly is pretty good (in general I don't like books with "Foo with Java" or "Bar with Qt" etc. - general concepts such as Design Patterns should be kept general, and if you have this knowledge it should be easily transferable to given technology (Java, Qt, .Net, ...). If I want to learn Qt I read its excellent documentation and tutorials ;) However, it is always nice if such books come with concrete examples, and said book shows code in C++ and Java (and yes, some languages support some concepts better than others).

Cheers, Oliver


--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22