[Qt-interest] Designing Qt applications

[Markus Franke]

Dear Oliver,

thanks for your detailed answer.

As I can read from your words it really depends on the project how GUI and 
application stuff can be separated from each other and how the MVC 
architecture can be implemented.

This actually completely represents the feeling I had before asking this 
question.

Never mind, it was still interesting to read some comments on this to get 
a better feeling how things should at least tried to be done. ;-)

Thanks again and best regards,
Markus

qt-interest-bounces at trolltech.com schrieb am 24.08.2010 11:05:55:

> 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
> 
> 
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest



"Disclaimer: This message is intended only for the use of the individual 
or entity to
which it is addressed and may contain information which is privileged, 
confidential, proprietary,
or exempt from disclosure under applicable law. If you are not the 
intended recipient or the person
responsible for delivering the message to the intended recipient, you are 
strictly prohibited from
disclosing, distributing, copying, or in any way using this message. If 
you have received this 
communication in error, please notify the sender and destroy and delete 
any copies you may have
received."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100824/ec0df667/attachment.html