9 ms·

How to architect a Qt/C++ Application

155 points by AlexFagrell 8y ago

AlexFagrell 8y ago
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 8y ago
  I'm going to write a GUI in 3 months using qt + rust. Bookmarking for later.
  - isatty2 8y ago
    Have you found any good tutorials or even documentation for using rust-qt? The bindgen that seems to show up on google search is very un-intuitive to use (or maybe that's because I'm a rust newbie)
    - fxfan 8y ago
      I seem to remember having come a Ross a link where the code objects in qml were rust and not Js. Can't find now. Seen this:? https://www.vandenoever.info/blog/2017/02/17/a-simple-rust-gui-with-qml.html https://www.vandenoever.info/blog/2017/02/17/a-simple-rust-g...
      - rapsey 8y ago
        That uses the qml crate that has not been updated in 2 years. Quite unlikely to not work at all. I've tried most QT Rust projects and none were all that usable. I'm afraid your plans are not likely to succeed.
        oever 8y ago
        I'm developing a few hobby projects with Qt and Rust. The Rust Qt Binding Generator I developed for that works so well for me that I've barely needed to improve it in months. https://www.vandenoever.info/blog/2018/10/30/building_qt_apps_with_cargo.html https://www.vandenoever.info/blog/2018/10/30/building_qt_app...
        rapsey 8y ago
        That json glue is quite ofputting tbh. I did try it, but failed building it on macos.
        oever 8y ago
        The JSON glue could be changed to Rust macros, but I've not found the time to do that. It's a bit ugly but free and works for me on Linux and I've had reports of success on Raspberry Pi and Windows. If it fails to build on Mac OS, I'd like to see why and help. The latest version uses Cargo for building, so e.g. `cargo qrep && qrep` should give you a working Rust + Qt example application.
      - pknopf 8y ago
        My project, Qml.Net (https://github.com/qmlnet/qmlnet https://github.com/qmlnet/qmlnet), does this as well, but with .NET.
  - vhakulinen 8y ago
    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/
    - fxfan 8y ago
      I have not but I looked at qml and find it elegant. I will give it a look.
    - dkersten 8y ago
      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.
      - vhakulinen 8y ago
        I have virtually no experience with Qt (as a developer). That said, I find the gtk-rs bindings good and easy to use in rust. They are automatically generated from C code, and as the generator matures the bindings come more and more complete. Tho' some of the bindings are manually written. AFAIK Gtk has QML counter part, but I haven't used that either. The documentation isn't perfect but its _really_ easy to map the documentation of the bindings to the original C documentation. From quick glance the situation seems to be more or less (maybe a bit less) the same with python bindings for Gtk. I personally have enjoyed the gtk-rs bindings.
      - uranusjr 8y ago
        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.
- ensiferum 8y ago
  You have too many CMakeFiles. I'm sure you can just simply them all into a single CMakeFile at the top level.
  - geezerjay 8y ago
    In the very least modern cmake requires one CMakeList.txt per module (application or library), not to mention the project.
    - ensiferum 8y ago
      No it doesnt. You can define multiple build targets in a si gle cmake file.
gwillz 8y ago
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.
emmanueloga_ 8y ago
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 8y ago
  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 8y ago
    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)
  - blattimwind 8y ago
    This is very sad indeed, because Qbs was both well architected and well executed. Very fast and the only build system where I never had to clean the build because the build system broke itself due to bad design/assumptions (e.g. mtime checking).
- berti 8y ago
  Qbs is (was?) a great build system even for non-Qt projects. The declarative syntax is simple, clear, and in no way Qt specific. Sadly it just never gained the traction it deserved.
- wink 8y ago
  From what I heard at the QtWS in December they're veeery slooowly deprecating qmake in favor of cmake, but I guess cmake is not yet the default and qmake won't be abolished for years, if ever... But the direction seems clear.
hydroreadsstuff 8y ago
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 8y ago
  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
- deleted 8y ago
  [deleted]
mitgraduate 8y ago
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.
- vhakulinen 8y ago
  How exactly is Electron superior? > VSCode is built in Electron. So is slack, which (from what I've heard, I have no personal experience) eats RAM like a maniac. Neither of these example applications tips the scale between Qt or Electron on being superior. Again, based on what I've heard/read, Qt being less recourse hungry and written in C++ allows it to be (for example) embedded (to cars or iot devices, for example).
- detaro 8y ago
  Because Electron is not "superior". Both have their strengths and weaknesses, and which one is the right choice depends on what you're doing and what your existing skills and components are.
- PostThisTooFast 8y ago
  Qt supports mobile development.
- dasloop 8y ago
  Why Electron is superior? We do mobility simulation and the UI part is the minor of our concerns. We are focused in modelling capabilities and performance (so C++). Having a solution that uses the same language across all the application layers help us a lot.
- pjc50 8y ago
  QT gives you a native-ish RAM-efficient GUI across a wide range of systems.
  - artemsyd 8y ago
    I thought QuickTime Player is only available on Mac OS nowadays.
pknopf 8y ago
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 8y ago
  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-performance.html#2d-hardware-acceleration http://doc.qt.io/QtQuick2DRenderer/qtquick2drenderer-perform...
  - ahartmetz 8y ago
    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 8y ago
      Thanks for the help!
quietbritishjim 8y ago
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 8y ago
glenrivard 8y ago
Really think Flutter is going to take the places Qt is used. Flutter just offers a better developer UX then Qt.

155 points by AlexFagrell 8y ago

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 8y ago
I'm going to write a GUI in 3 months using qt + rust. Bookmarking for later.
- isatty2 8y ago
  Have you found any good tutorials or even documentation for using rust-qt? The bindgen that seems to show up on google search is very un-intuitive to use (or maybe that's because I'm a rust newbie)
  - fxfan 8y ago
    I seem to remember having come a Ross a link where the code objects in qml were rust and not Js. Can't find now. Seen this:? https://www.vandenoever.info/blog/2017/02/17/a-simple-rust-gui-with-qml.html https://www.vandenoever.info/blog/2017/02/17/a-simple-rust-g...
    - rapsey 8y ago
      That uses the qml crate that has not been updated in 2 years. Quite unlikely to not work at all. I've tried most QT Rust projects and none were all that usable. I'm afraid your plans are not likely to succeed.
      - oever 8y ago
        I'm developing a few hobby projects with Qt and Rust. The Rust Qt Binding Generator I developed for that works so well for me that I've barely needed to improve it in months. https://www.vandenoever.info/blog/2018/10/30/building_qt_apps_with_cargo.html https://www.vandenoever.info/blog/2018/10/30/building_qt_app...
        rapsey 8y ago
        That json glue is quite ofputting tbh. I did try it, but failed building it on macos.
        oever 8y ago
        The JSON glue could be changed to Rust macros, but I've not found the time to do that. It's a bit ugly but free and works for me on Linux and I've had reports of success on Raspberry Pi and Windows. If it fails to build on Mac OS, I'd like to see why and help. The latest version uses Cargo for building, so e.g. `cargo qrep && qrep` should give you a working Rust + Qt example application.
    - pknopf 8y ago
      My project, Qml.Net (https://github.com/qmlnet/qmlnet https://github.com/qmlnet/qmlnet), does this as well, but with .NET.
- vhakulinen 8y ago
  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/
  - fxfan 8y ago
    I have not but I looked at qml and find it elegant. I will give it a look.
  - dkersten 8y ago
    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.
    - vhakulinen 8y ago
      I have virtually no experience with Qt (as a developer). That said, I find the gtk-rs bindings good and easy to use in rust. They are automatically generated from C code, and as the generator matures the bindings come more and more complete. Tho' some of the bindings are manually written. AFAIK Gtk has QML counter part, but I haven't used that either. The documentation isn't perfect but its _really_ easy to map the documentation of the bindings to the original C documentation. From quick glance the situation seems to be more or less (maybe a bit less) the same with python bindings for Gtk. I personally have enjoyed the gtk-rs bindings.
    - uranusjr 8y ago
      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.
ensiferum 8y ago
You have too many CMakeFiles. I'm sure you can just simply them all into a single CMakeFile at the top level.
- geezerjay 8y ago
  In the very least modern cmake requires one CMakeList.txt per module (application or library), not to mention the project.
  - ensiferum 8y ago
    No it doesnt. You can define multiple build targets in a si gle cmake file.

gwillz 8y ago

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.

emmanueloga_ 8y ago

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 8y ago
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 8y ago
  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)
- blattimwind 8y ago
  This is very sad indeed, because Qbs was both well architected and well executed. Very fast and the only build system where I never had to clean the build because the build system broke itself due to bad design/assumptions (e.g. mtime checking).
berti 8y ago
Qbs is (was?) a great build system even for non-Qt projects. The declarative syntax is simple, clear, and in no way Qt specific. Sadly it just never gained the traction it deserved.
wink 8y ago
From what I heard at the QtWS in December they're veeery slooowly deprecating qmake in favor of cmake, but I guess cmake is not yet the default and qmake won't be abolished for years, if ever... But the direction seems clear.

hydroreadsstuff 8y ago

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 8y ago
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
deleted 8y ago
[deleted]

mitgraduate 8y ago

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.

vhakulinen 8y ago
How exactly is Electron superior? > VSCode is built in Electron. So is slack, which (from what I've heard, I have no personal experience) eats RAM like a maniac. Neither of these example applications tips the scale between Qt or Electron on being superior. Again, based on what I've heard/read, Qt being less recourse hungry and written in C++ allows it to be (for example) embedded (to cars or iot devices, for example).
detaro 8y ago
Because Electron is not "superior". Both have their strengths and weaknesses, and which one is the right choice depends on what you're doing and what your existing skills and components are.
PostThisTooFast 8y ago
Qt supports mobile development.
dasloop 8y ago
Why Electron is superior? We do mobility simulation and the UI part is the minor of our concerns. We are focused in modelling capabilities and performance (so C++). Having a solution that uses the same language across all the application layers help us a lot.
pjc50 8y ago
QT gives you a native-ish RAM-efficient GUI across a wide range of systems.
- artemsyd 8y ago
  I thought QuickTime Player is only available on Mac OS nowadays.

pknopf 8y ago

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 8y ago
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-performance.html#2d-hardware-acceleration http://doc.qt.io/QtQuick2DRenderer/qtquick2drenderer-perform...
- ahartmetz 8y ago
  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 8y ago
    Thanks for the help!

quietbritishjim 8y ago

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 8y ago

glenrivard 8y ago

Really think Flutter is going to take the places Qt is used. Flutter just offers a better developer UX then Qt.