QStandardItemModel::​QStandardItemModel(QObject * parent = 0)
Constructs a new item model with the given parent.
I thought models can share multiple views then why we are passing a widget to QStandardItemModel Constructor?
Actually QObject is not a widget, so that model is not dependent on any GUI component. The QObject argument passed to constructor because QStandardItemModel is a QObject itself and it follows Qt's standard parent-child relationship in QObjects hierarchy. If you want your model instance get deleted when its parent object destroyed, pass its pointer to the model's constructor.
Related
I have an abstract class representing data objects. Each object represents one data item. The derived classes implement the function updateValue() that gets called periodically in a thread to compute new values. All these classes are from a non-Qt C++ library.
Something like:
class DataObject
{
double value;
virtual void updateValue() = 0;
};
At present, I have several types of QWdiget based display widgets, each widget tied to a DataObject. Something like:
class DisplayWidget
{
DataObject *dataObject;
virtual void updateDisplay() = 0;
};
The widgets could be simple QLabel boxes, Qwt-based dials, gauges etc. The application has multiple pages, each page containing several of such widgets. At every 100ms or so (QTimer tick), I iterate through all widgets in the current page and call updateDisplay() for each of them to update their display.
NOW: I want to have some shiny Qt Quick based widgets/pages, that I can generate using qml files. I can use a QQuickWindow container widget on a page, whose contents are loaded from a specified qml file at runtime.
My question is how do I efficiently export/map my C++ DataObject objects to corresponding QtQuick widgets so that I can periodically update the display?
Since DataObject class and its children are from a non-Qt library, I cannot create properties and notifier signals in those classes
I can of course create wrapper class object for each object that needs to be displayed in QtQuick window. This wrapper class will need to be derived from QObject and have properties and notifier signals. Then periodically on display timer tick, I'll need to emit the notifier signal (may be after checking if the corresponding data object's value has actually changed since the last update).
When the QML file is loaded, I'll need a way to dynamically create the wrapper objects for each DataObject that the file needs.
Is this the most efficient and elegant way to do this? I may need about a hundred display widgets on a page.
One of our teacher asked us to create a Qt application without any UI file for the main window (a QMainWindow). Usually I always create one, leave it empty and let the uic deal with it.
I know that if a parental relation is defined between a widget (child) and its parent, then there is no need to delete the widget (deleted when the parent is deleted). So, when the UI is deleted, all the children are destroyed.
If we do not use an UI file (not generated), do we have to manually delete all the widget added to the GUI?
A little sample:
MainWindow::MainWindow(QWidget* parent) : QMainWindow(parent){
layout = new QHBoxLayout(this);
aButton = new QButton(this);
layout->addWidget(aButton);
...
}
MainWindow::~MainWindow(){
delete ui; // No need to delete more if parental relation.
// However, what do we do if no ui has been generated?
// Do we have to delete aButton?
}
The value of parent is 0. It is the main entry of the application.
Thanks
Please refer to this article
QWidget, the fundamental class of the Qt Widgets module, extends the parent-child relationship. A child normally also becomes a child widget, i.e. it is displayed in its parent's coordinate system and is graphically clipped by its parent's boundaries. For example, when the application deletes a message box after it has been closed, the message box's buttons and label are also deleted, just as we'd want, because the buttons and label are children of the message box.
So, there is no difference do you use ui or not. When you delete window, all its children will be deleted too.
I have a QAbstractListModel descendant class with list of instances of my arbitrary type MyItem inside. Also I have a ListView with model binding to that QAbstractListModel descendant.
All I want to do is to bind handler in delegate of ListView to the signal of my arbitrary type MyItem. Is there any way to do it?
UPD. I don't want to bind delegate to signal of a model so when I will have many items all of them will be triggered. I want to notify only one delegate with a signal.
If I subclassed any widget the usual pattern is:
ZTabWidget::ZTabWidget(QWidget *parent):QTabWidget(parent){
blah ... blah ...
}
The usual pattern is:
WidgetB widgetb = new WidgetB(widgeta)
widgeta.addWidget(widgetb);
Is there any harm in having all my widgets assigned MainWindow as their respective parent - even though, following the trails of addWidget hierarchy, most of those widgets have another widget as the addWidget parent:
WidgetB widgetb = new WidgetB(mainWindow)
widgeta.addWidget(widgetb);
The reason I wish to do this is because mainWindow holds all the main items of the application and that I could have my any of my subclassed widgets reference those items.
In fact, I am thinking of a proxy widget that is merely used to hold some common references and use that proxy widget as the common parent of all my widgets. Any problem in that?
Exactly, what is the use of having registered a parent for a QWidget? Is the parent even used internally?
Does the addWidget parent have to be the same as the constructor parent?
There are actually two aspects two your questions:
Memory management
The tree-like organization of QWidgets (and in fact of any QObjects) is part of the memory management strategy used within the Qt-Framework. Assigning a QObject to a parent means that ownership of the child object is transferred to the parent object. If the parent is deleted, all its children are also deleted. From the docs:
QObjects organize themselves in object trees. When you create a
QObject with another object as parent, the object will automatically
add itself to the parent's children() list. The parent takes ownership
of the object; i.e., it will automatically delete its children in its
destructor. You can look for an object by name and optionally type
using findChild() or findChildren().
This means you can organize your widgets in any way that seems sensible to you (as long as you don't introduce memory leaks). I think, however, that it is a common practice to assign all the widgets to their respective container (either explicitly, or better, using methods like addWidget).
If a widget is assigned to a QLayout using addWidget, then ownership of the widget is transferred to the layout (which in turn is probably owned by another surrounding layout or the main window). So yes, the relationship defined by this method includes the more general parent-child relationship described above.
Now, as soon as the main window gets destroyed, basically the whole tree of QObjects is deleted as you'd expect.
Consequently, if you leave an object "parentless", it is your own responsibility to delete it.
GUI semantics
As Frank noted correctly, in some contexts the parent-child relationship between QWidgets also bears a semantically meaning to the GUI framework. An example of this are modal dialogs, who block their parent as long as they stay open.
I'm repeatedly using a pair of QComboBox and QListWidget in a project. Their interaction is highly coupled - when an item is selected in the combo box, the list is filtered in some way. I'm copy pasting all the signal and slot connections between these two widgets across multiple dialog box implementation which I don't think is a good idea.
Is it possible to create a custom widget, which will hold these two widgets and will have all signal and slot connection in one place? Something like as follows:
class CustomWidget
{
QComboBox combo;
QListWidget list;
...
};
I want to use this widget as a single widget.
The usual way of doing this is to sub-class QWidget (or QFrame).
class CustomWidget: public QWidget {
Q_OBJECT
CustomWidget(QWidget *parent)
: QWidget(parent) {
combo = new QComboBox(...);
list = new QListWidget(...);
// create the appropriate layout
// add the widgets to it
setLayout(layout);
}
private:
QComboBox *combo;
QListWidget *list;
};
Handle all the interactions between the list and the combo in that custom widget (by connecting the appropriate signals to the appropriate slots, possibly defining your own slots for this).
You then expose your custom widget's behavior/API through dedicated signals and slots, possibly mimicking the ones in the list and/or the combo.
The Address book tutorial walks you through all of that, including creating a custom widget and defining signals and slots for it.