
How to architect a Qt/C++ Application - AlexFagrell
https://www.cleanqt.io/blog/crash-course-in-qt-for-c%2B%2B-developers,-part-7
======
AlexFagrell
Hi guys, This is the 7th post in the series "Crash course in Qt for C++
developers." Do you structure and architect your application in a similar way?
Let me know what you think and I would appreciate if you have any feedback.

~~~
fxfan
I'm going to write a GUI in 3 months using qt + rust. Bookmarking for later.

~~~
vhakulinen
You should checkout gtk-rs[0] too if you're settled on rust but have an option
to pick other GUI library.

0: [https://gtk-rs.org/](https://gtk-rs.org/)

~~~
dkersten
Can you say a little bit about what makes it great? Is it just a well designed
wrapper? Super easy to use? Good documentation? More mature than Rusts Qt
bindings?

Personally, I like Qt a lot more than GTK (both as a programmer and a user),
but to each their own. QtQuick/QML is really great way of quickly whipping
together complex UI’s. I’ve never used Qt on Rust though.

~~~
uranusjr
Hopefully my experience could be useful, having tried rust-qt just a while ago
on a project. Bottom line: it is usable.

It is pretty trivial if you want to build an almost purely QML app. As soon as
you want to do some C++ stuff (e.g. registering new C++ classes, using
QtWidgets), however, things go south _very_ quickly. The main problem is that
Qt has its own ideas about ownership (QObject-parent-stuff), and Rust really
does not like that. You end of working a lot with raw pointers and boxes. It
feels like you’re writing C++ but in Rust (if that makes sense).

Rust-qt is really nice IMO, and I would extremely encourage anyone interested
to take a look, and provide more feedbacks and contributions to the
maintainers (I am not one of them). Some non-trivial examples would help a
lot. But expect sharp edges.

------
gwillz
Hey thanks, I'm really enjoying this series. It's nice to read a clear
approach after the many revisions to the C++ standard.

Keen to see more on the QtQuick/QML stuff. I keep reading things about how
great it is but never had the time to get into it.

For your "good-to-know topics" perhaps a brief direction for deploying
applications? Bonus points for mobile deployment.

------
quietbritishjim
I disagree with your diagram of model-view-controller. Traditionally, the view
and the controller are both part of the user interface, so should be on the
top part of your diagram. In fact the controller is _higher level_ than the
view.

The distinction between these two parts is that the view is just a display of
the data (model) whereas the controller is a way for the user to edit it. This
was more relevant back in the 1970s where these things were more often
separate. For a modern(ish) example, think of Vim's separation between the
main display of your text file (the view) and its command line at the bottom
(the controller). In most modern GUIs this distinction is meaningless, so you
would group controller and view into the view and have a simple overall model-
view separation.

Now I'm not saying that all of the classes you've called (something)Controller
should be moved to the UI, I'm just saying that they're misnamed (at least by
the traditional definitions). I _think_ that your interpretation of model vs
controller is raw model data vs non-graphical operations that act on them. But
operations on the data are just as much part of the model as the data itself.
For example, if I have a word processor then my model is a document, including
operations on it. If I want to update the document programmatically (bypassing
the GUI), for example to add a word, then I expect to call a method of the
model. This should do everything to keep the model consistent, such as
returning an updated word count. But that still doesn't need anything called a
controller.

I just said that I'm not telling you to move your controller classes to the UI
(view) layer. But that's a general comment about the meaning of "model view
controller". The specific example you present on that page is "MenuModel" and
"MenuController". These sound like things that _both_ belong in the UI layer.
Going back to the word processor example, your model might have a SaveToFile()
method (although it would expect a file name parameter - popping up a save
file dialogue box is the UI's job). But it won't know whether that came from a
File->Save menu item or the user hitting ctrl+S. It's the UI's (view's) job to
create a menu, choose what commands go on it, and map the OnClick events to
actions on the model.

No doubt others will disagree with my understanding of the definition of
"controller". This is the one thing you can be really sure about with that
term! And it's another good reason to avoid it. Everyone agrees with "model"
and "view" mean, so if you use those terms then people will know what you
mean, but if you describe something as a "controller" then it just causes
confusion.

~~~
de_watcher
> so you would group controller and view into the view and have a simple
> overall model-view separation.

> ...

> But operations on the data are just as much part of the model as the data
> itself.

So you want to move controller into the view or to the model? I can't tell. :)

~~~
quietbritishjim
Sorry if that wasn't clear.

I understand the term "model" to include non-graphical operations on model
data. For example, SaveToFile() or InsertTextAtPosition() methods. These
should definitely NOT be merged with the view!

\--> I believe that the linked article called these non-graphical operations
"controllers", but I disagree.

\----------------

I understand the term "controller" to be graphical controls that allow
manipulation of the data. For example, a the QMenuItem "save" along with its
associated signal (which of course will just call a method on the model), or
the OnKeyPress handler on an edit control.

\--> I believe that the linked article just considers these to be part of the
"view". I'm actually OK with this, because I the distinction between
controller (in this sense) and view is not very useful.

------
pknopf
You go just use QML and C# as well.

[https://github.com/qmlnet/qmlnet](https://github.com/qmlnet/qmlnet)

Disclaimer: I'm the author.

~~~
quietbritishjim
Apologies for the somewhat off-topic questions:

* Could this be mixed into an existing C# WinForms applications? I'm just talking about using a mix of different window types; I don't want/expect a mix within individual windows.

* Do you know if QT Quick has significantly better performance than WinForms for 2D graphics? I know that WinForms is not hardware accelerated (because it's based on GDI+ which was abandoned by Microsoft before they added hardware acceleration support). But I find documentation about QT Quick's hardware acceleration vague and confusing e.g. [1].

I work on an old WinForms application that makes heavy use of traditional 2D
graphics APIs (i.e. Pen and Brush objects used during OnPaint events) but
performance is a significant practical problem, and I'd like to find a way to
move to something faster somewhat incrementally. My current thinking is to use
WPM for new windows, but QT might be a bit nicer.

[1] [http://doc.qt.io/QtQuick2DRenderer/qtquick2drenderer-
perform...](http://doc.qt.io/QtQuick2DRenderer/qtquick2drenderer-
performance.html#2d-hardware-acceleration)

~~~
ahartmetz
Well, you are looking at the description of the software renderer. Qt Quick is
hardware accelerated (OpenGL) by default. A subset of it is supported by the
software renderer. With hardware acceleration, performance is generally great.

Actual rendering overview (rather technical): [http://doc.qt.io/qt-5/qtquick-
visualcanvas-scenegraph.html](http://doc.qt.io/qt-5/qtquick-visualcanvas-
scenegraph.html)

Cool blog post about performance improvement through draw call batching:
[http://blog.qt.io/blog/2013/09/02/new-scene-graph-
renderer/](http://blog.qt.io/blog/2013/09/02/new-scene-graph-renderer/)

~~~
quietbritishjim
Thanks for the help!

------
emmanueloga_
re: clean. What happened to Qbs? [1] Is it still not popular?

I ask because this same tutorial has an explanation on how to use CMake with
Qt. Arguably Qbs is a lot "cleaner" than CMake scripting... but it doesn't
appear to be a popular choice.

1: [http://doc.qt.io/qbs/](http://doc.qt.io/qbs/)

~~~
AlexFagrell
Agree, unfortunately the Qt company decided to "deprecate" it, or rather to
not put anymore resources into it:
[http://blog.qt.io/blog/2018/10/29/deprecation-of-
qbs/](http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs/)

~~~
cannam
Reading that post and the comments makes me want to try out Qbs! I was vaguely
aware of its being announced a few years ago, but I hadn't realised it had
even become mature, let alone deprecated. Sounds like a good match for some of
my gnarlier qmake-based projects. (Can't abide CMake)

------
hydroreadsstuff
How can I follow this blog? I don't see RSS. Feedly doesn't know it. And there
seems to be no email option either.

How do you follow blogs in general these days. My twitter is too full of
things, so I'd probably miss the posts sometimes.

~~~
AlexFagrell
Hey buddy! I've meant to add RSS and email to the blog but haven't got around
to do it yet. Sorry... Thanks for the reminder though, I'll see what I can do
over the weekend! Cheers, Alex

------
mitgraduate
I just want to ask, why?

Today we've a superior technology like Electron. Why should we use old
technology like Qt?

VSCode is built in Electron.

~~~
seren
In the embedded world, you have much more chance to run QT than Electron,
because QT also supports RTOS like VxWorks or QNX.

~~~
blattimwind
Qt also has a renderer that's simply superior by design for embedded use
cases. A web engine has to bent over backwards to do anything comparable.

~~~
ahartmetz
Yes. HTML + DOM + CSS + JS was not created to write interactive applications,
and it _still_ shows. Most of the inconvenience can now be worked around with
frameworks, but a large performance penalty remains. And Moore's Law is over.

