making worker and widget aware of one another
-
Hi all -
I need to create a display with a list of items. The raw data is in a QStandardItemModel. In the past, I've created made my worker and widget objects aware of each other by passing pointers in at construction. I'm wondering if there's a cleaner way to do this? The goal is to have a line like:
Widget::Widget(QWidget *parent) : QWidget(parent) , ui(new Ui::Widget) { ui->listView->setModel(I_need_to_know_the_model_for_this)
What might be a straightforward way of doing this?
Thanks...
-
Hi,
Does it really need to be known at construction time ?
If not, then you can add a setModel method to your widget. -
@SGaist no, it's not necessary to do it at construction time, but...I'm still faced with how to access the model from the widget. Currently, I do it like this in main.cpp:
Widget *w; Worker *worker; QAbstractItemModel *model; model = new QStandardItemModel(); w = new Widget(model); worker = new Worker(model);
But this seems like a hack to me (but maybe it isn't).
-
I don't see where the hack is.
You have a model used by different object in a similar fashion as multiple views looking at the same model, haven't you ?
-
@SGaist well yes, but...just as an example, let's say I decided to change from an item model to a table model. I'd have to chase down every place I coded that object type. (Maybe I'm splitting hairs.) Do people typically create their models at the top-level, or in their worker objects?
On this subject, I'm not sure that the list item/view is the way to go. Eventually, each row in the list will contain some paintable objects. My thought was to create an object to represent the list element. Is this a sensible way to go, or is there a better architecture to use?
Thanks...
-
That's why setModel accepts a base class (usually abstract) so you can use several different models as they have a standard interface.
Since you have a model that is used in several other objects, you would create the model in the class that manages all these objects.
Model/View does not lock you to the Qt classes. It's a pattern that you can implement in different ways. From your description, it seems to be a good plan.