error: 'QWidget::QWidget(const QWidget&)' is private Q_DISABLE_COPY(QWidget)

[VRonin]

QObjects can't be copied. you can have a QList<QWidget*> but not a QList<QWidget>.

Having said that. Stop immediately whatever you are doing.
The model should not take care of rendering.
If you want to color a cell just use QStandardItemModel and call model->setData(model->index(row,column),QBrush(Qt::black),Qt::BackgroundRole );
See http://doc.qt.io/qt-5/model-view-programming.html for more details on model/view/delegate

[Niagarer]

@VRonin
Ok, thanks.
Just thought, this would be a legitim way, because I just looked to the puzzle-example and there it is also made this way (but with Pixmaps) and this example shows what I want to have in the end.

[SGaist]

Hi,

QPixmap is not a QObject that's why it works in that case. Not all Qt classes derive from QObjects.

[Niagarer]

@SGaist
Ohhh, that makes sense.
Now I use a delegate class and I want to display a custom widget by me to get what I tried to do above. The model holds only the title (and some more icons later) and the view just should display these custom widgets as items (and in the custom widgets, the corresponding title will be shown). How can I make my delegate class creating and displaying these widgets (I already have the widget class) and using them as items in the ListView?

[VRonin]

• Do you really need to display widgets?
• could you handle the paint efficiently yourself?

If you really answered yes and no then you can use: https://pastebin.com/XrppLZ3m but be mindful performance will be impacted

[Niagarer]

@VRonin
Ok... I just don't get the problem here...
Everywhere in every program we use, we have lists of widgets (or a treeView), that are draggabe into another area/over another widget, that then reacts to it. Why is this such a problem?
I don't know exactely what you mean with handeling the paint event myself. Why can't I just change the displaying part. Anywhere, there must be a function, that draws the items of the list. Why can't I just redict the painting signal to the correseponding widget?

[mrjj]

@Niagarer
Having a list of real widgets is heavy to draw.
if you plan on run on smaller boards ,it will not
scroll nicely if u have many items.
The solution to this - is a delegate the at draw the look of the widget,
but it IS not a full widget unless you click on it.
When clicked Then delegate via Editor, use a the real widget and user can interact with it on the
current select row/col. As soon as its not the active one, its only drawn by
manual painter operations.
That is how a delegate help performance.
By NOt being a big is list of real widgets but only the current one is real and rest
is not.

Try the code VRonin links to. its his creation and very useful!

[Niagarer]

@mrjj
Ok, makes sense.
Is it possible to anyway seperate the delegate from the actual widget painting in code? So that I can do something like

void MyItemDelegate::paint(QPainter *painter, /* and all other stuff */) const{
    widgetItems.value(index.row())->myCustomPaintFunction(painter); // widgetItems = QList<WidgetItem*> widgetItems;
                                    //WidgetItem = just a standalone C++ class
}

WidgetItem::myCustomPaintFunction(QPainter *painter){
    // draw the shape
}

It would be a bit clearer to seperate it this way

[VRonin]

In general yes, what you wrote, however is conceptually wrong. widgetItems.value(index.row()) implies the delegate owns/is the model which is unusual at least

[Niagarer]

@VRonin
Well yes, I should store the actual data in a model, that is able to return this data correctly.