We just create models and use context properties. Or have the QML code request the model from another object via function or property. We generally have an application object that manages the lifetime of the smaller objects.

You cannot, without modifying the class where the private member is declared. That's why it was made private. Without a get/set method pair it is only visible internally to the class.

@mingvv

First, you should understand the basics of C++ and object-oriented programming in general. Without it's really hard to get a satisfying result and you will spend most of your time looking for things or trying to figure out how things work (or why they don't).

Qt also has Model-View based classes.

https://doc.qt.io/qt-5/model-view-programming.html

You can communicate with your GUI or other QObject classes using the Qt signal&slot system or using events.
For example if you press a button, you will emit the clicked signal. Then, if you connect a slot (= function) to this signal, the function will be called to perform some actions.

https://doc.qt.io/qt-5/signalsandslots.html

A (simple) snake game in Qt might be a practice to start with. Think about what classes / structure you will need, design your GUI and start writing your code :)

Might be helpful:

https://doc.qt.io/qt-5/graphicsview.html

According the "GUI Code vs Designer" thing:
It's mostly a mix of both. Some things just can't be done using the QtDesigner, but it helps a lot creating your basic widgets and your basic design.

@jsulm Ok, thanks a lot for the help

@Yash001 if your issue is solved (aside for the fact that you need to read and incorporate several concepts, I guess), please don't forget to mark this post as solved. Thanks.

Thank you very much for your answers, because they have been very useful to solve a problem within my application.

@BjornW said in Signal and slot to synchronize variable between qthread:

I would separate the objects into two types. One type that is the "master" object and other objects which interact with it.

That's the correct thinking, I consider this whole question to be a design issue. The problem I see is that a dependency is introduced between two QObjects that are in different threads, that is very unnatural to begin with - the two objects shouldn't depend on one another implicitly; it's no mistake that a QObject instance can't have a parent that's living in another thread. In my mind either the dependency should be declared explicitly (e.g. manually synchronizing the objects across the threads in some fashion) or it shouldn't exist at all.

Hi there,

I have some experience in software development (about 30+ years or so), and never ever was your question leading...

First choose what devices your app should be running on
Then decide if your app has enough "reusable" things to even start thinking about models
If not, don't use any model at all! It will only cost you more time. Don't let the "hype" trick you!

However, if ur app is supposed to work on several different devices, and the output of your app may be in different kinds of forms, THEN, and only THEN, start thinking about how to generalize the view of ur app to the different kinds of users...

And also ofcourse, If you plan to make many apps, some parts may be common. And Yes, in that case you start worying about reusability.

But NEVER!!!
NEVER EVER!!!
Worry about UI, before u have thought about ur app first:

What it should do

How it should do it

What UI should be the LAST of ur problems...

Now, having sayd that, there is always "Prototyping" to engage the end users in the look and feel of the app in as early a stage as possible of course, but it NEVER should be leading to a change of architecture.

@p3c0

Thanks a Lot.

As you said, I will use the profiler now and then.

@Rohith

A controller is simply an object that controls both the model and the view. The following brief example should get you started:

class MyController : public QObject { Q_OBJECT public: MyController(QObject * parent = NULL) : QObject(parent) { view.setModel(&model); } int exec() { view.show(); return QApplication::exec(); } private: // ... QTreeView view; QFileSystemModel model; };

And you use simply by creating the object and invoking the appropriate method(s).

int main(int argc, char ** argv) { QApplication app(argc, argv); MyController controller; return controller.exec(); }

@asanka424

However in my experiece, MVC cannot be implemented as cleanly as in a web application for a desktop application. Main reasone is that all UI widgets have some sort of controller embedded in already.
For that reason Qt has something called Model-View architecture which is not the MVC pattern but something similar to de-couple your data from the view.

Qt only applies the view as controller, but doesn't actually "require" the user programmer to follow. The same effect as and I'd say better could be obtained by separating the logic. One thing that springs to mind: no need to derive a whole class only to have a form initialized in the constructor.

The only problem with MVC is that it's used with and without reason (as all "architectural" and "design" patterns are), because people are mislead to believe them as one size fits all solution.

Kind regards.

I like the proposed architecture by Ben Lau a lot!

However, for small QML apps, you can also introduce a similar pattern with a smaller and lightweight solution purely in QML.

If you're interested, you can find the full developer guide here: https://v-play.net/apps/avoid-cpp-models-qt

Cheers,
GTDev