Please nominate your Qt Champions for 2021!

C++ model (QAbstractItemModel) with Qt Quick view?

  • Moderators

    [quote author="logic_cube" date="1375103590"]So for example, let's say that I have a view-model type architecture where the UI layer is also required to perform some complex UI related processing and even keep UI related state, are you saying that I should still develop this in QML / Javascript? Or should this UI layer be split between two UI implementation langauges of C++ and QML / JavaScript?[/quote]What kind of complex UI processing are you talking about?

    For a recent project, I subclassed QTableView in C++ to implement a spreadsheet-like widget, and I used QML to implement a dynamically-updated, interactive (draggable) tree graph. Both are complex, but both had different requirements which were best served by different languages/frameworks.

    QML's property binding feature and simple drag API made it dead easy to implement my interactive tree (less than 300 LOC in total, including pop-up menus and communications with my C++ bits). I didn't have to write any code to track node positions and update edge lines.

    However, QML is still young. While it has some awesome features, it still lacks some of the abilities of C++. Two important things were missing in QML for my spreadsheet (or maybe I just haven't found them yet):

    • I couldn't access the clipboard from QML
    • I couldn't get a QML view to use a traditional C++ QAbstractItemModel. The latter was a must, as my models go through lots of programmatic manipulation

    It was easy enough to extend a QTableView in C++, so that was the natural path to take.

    [quote]For example, I have seen that some QML files can become quite large and there is no encapsulation (except maybe double underscore for private variables, etc), how does this affect the design choices that need to be made?[/quote]I'd say that design choices should be guided by tried-and-true paradigms, not by language features (or the lack thereof). If the language doesn't provide encapsulation formally, then work out some good rules rules with your team and stick to them (e.g. "Put 'private' QML types in specially-labelled subfolders that only the 'owner' should access. Fight the temptation to dip into someone else's subfolder.")

    If a QML file gets too large, I do that same thing I'd do with a C++ file: Split it into smaller components.

    Also, regarding encapsulation of member variables, there are tricks like this:
    // MyComponent.qml
    Rectangle {

    // Private object, not accessible to other files
    QtObject {
        id: p
        property int foo: 0
        property int bar: 0
    function mySlot() {
        return +


    foo and bar are not accessible from other files. However, it requires the construction of an extra QObject which can be expensive.

    [quote author="logic_cube" date="1375175303"]@JKSH - "QML is designed for writing GUIs, so use it to write your GUI. It lets you describe complex GUIs with very little code" - Does this mean that if I find myself writing a lot of QML / Javascript code that it is an anti-pattern, especially as the QML / Javascript system does not seem to support a lot of the facilities you would except when having to write large systems, e.g. encapsulation...[/quote]Sorry if I was misleading. I meant "little code" when compared C++ in general (see my tree example above). And when you find something missing in QML/JavaScript, just go with C++ (see my spreadsheet example above).

    I wouldn't go as far as calling it an anti-pattern. There's just two perfectly valid ways of doing things. One might take more effort than the other, but it can still be a robust solution. Also, the size of your files is obviously proportional to the scope of your program -- it's not necessarily a sign of bad practices.

    One thing I didn't mention in my previous post was "Qt Designer": -- it's a WYSIWYG editor that lets you drag-and-drop traditional C++ widgets, and takes care of lots of the code generation for you. It also reduces coding effort (which is one of the main reasons I use QML)

    [quote]Part of the confusion for me came in when I discovered the mixed declarative / imperative programming model of the QML / Javascript system and hence knowing when to use QML / Javascript and when to use C++. I guess having to maintan these systems will bring some answers ;-) [/quote]Don't get too paralyzed trying to figure out the "best" way to do something -- the answer will come most naturally when you try it out. Personal preferences and experience also play a part.

    I sometimes get to the end of a project and think, "Gee, life would've been easier if I had done things THAT way instead!" -- well, too late for this project, but I'm now wiser for my next project :)

Log in to reply