is making everything a QObject bad practice?
-
I have a simple mvc architecture, is it bad to connect the model to the ui through signals/slots? Because I will have to make every model class inherit qobject and i feel that makes everything tightly coupled.
-
Hi,
This is a very general question and therefore hard to answer. Generally nothing is wrong with signal/slot connections. And if you want to display data from a model, you don’t have many other choices. Maybe expand more about your use case and your code. -
I have a simple mvc architecture, is it bad to connect the model to the ui through signals/slots? Because I will have to make every model class inherit qobject and i feel that makes everything tightly coupled.
@Mbkerdellou
Yes, where you want signals/slots you will needQObject. Including everything model<->UI, that is normal and expected. All Qt models ultimately inherit fromQAbstractItemModel, which isQObject, and you would be advised to make your models derive fromQAbstractItemModelor one of its subclasses too, so you will getQObjectand the MV signals anyway.Where you have other classes which do not need signals/slots or other
QObjectfeatures do not inheritQObjectjust for the sake of it. As an example, all the Qt "utility" classes, e.g.QList,QVariantorQFileInfo, do not. -
I have a simple mvc architecture, is it bad to connect the model to the ui through signals/slots? Because I will have to make every model class inherit qobject and i feel that makes everything tightly coupled.
@Mbkerdellou Hi,
As @Axel-Spoerl wrote, you're a bit light on details.
From you description you seem to have a certain amount of data structure that you want to expose to views.
One possible way to implement that without having to refactor everything and make them all QObject is to write your own model(s) that will act as wrapper around these structure. That way you can keep things separated.
