Using Qt::UserRole in the Model/View architecture

[d_stranz]

Thanks. I think I basically understand this now. I was hoping I might be able to use user roles as an automatic part of the framework but apparently I can't.

My implementation problem is this: I have implemented a custom QTableView that contains QwtPlot instances in the cells of two columns. The solution I implemented was to implement a slot for the model's modelReset() signal. In this slot, I create the QwtPlot and use setIndexWidget() to put them into the view. This seems to me to be a kludgy way to do this, but it works.

I had tried using a custom delegate to wrap the QwtPlot instance, but I couldn't find an appropriate place to create the QwtPlot instance. The createEditor() method isn't it, because the cell isn't editable, and my understanding is that the same delegate instance could be used for the entire view (if calling QAbstractitemView::setItemDelegate()), so I can't create the widget in the delegate constructor.

So, is there a better (i.e. more elegant) way to accomplish what I'd like to do using user roles and/or delegates that doesn't involve this out-of-band kludge?

I've attached a screenshot of this table.

QwtPlotTable.jpg

[wysota]

if you use setIndexWidget then the widget you set has no relation to the model-view architecture -- it is just a standalone widget positioned somewhere in the view widget.

if you want to display a plot in a view then a better solution is to implement a custom delegate that will (in its paint routine) use QwtPlot::print or something similar to render a plot in the item without explicitly showing any widgets.

[d_stranz]

if you use setIndexWidget then the widget you set has no relation to the model-view architecture -- it is just a standalone widget positioned somewhere in the view widget.

Right. That's why I consider it a kludge.

if you want to display a plot in a view then a better solution is to implement a custom delegate that will (in its paint routine) use QwtPlot:rint or something similar to render a plot in the item without explicitly showing any widgets.

That would be very "heavy", since I would have to temporarily instantiate a QwtPlot, configure it (which is where the user role data would come in), render it, then delete it, on every paint event on every delegate that contained a plot. I understand that using a custom delegate would be the correct way to do it within the M-V architecture.

I'll think about that for the next time I need to do something like this. The current project is too close to release to do so much experimentation.

[wysota]

That would be very "heavy", since I would have to temporarily instantiate a QwtPlot, configure it (which is where the user role data would come in), render it, then delete it, on every paint event on every delegate that contained a plot. I understand that using a custom delegate would be the correct way to do it within the M-V architecture.

I don't know Qwt very much unfortunately but maybe there is a class that allows you to build a plot that is not a widget, then it should be somewhat lighter. On the other hand if you use setIndexWidget then you end up with a similar architecture anyway, the difference is whether it is tied to the model-view arch. or not. And the overall performance also depends on which solution you choose.

[d_stranz]

I don't know Qwt very much unfortunately but maybe there is a class that allows you to build a plot that is not a widget, then it should be somewhat lighter. On the other hand if you use setIndexWidget then you end up with a similar architecture anyway, the difference is whether it is tied to the model-view arch. or not. And the overall performance also depends on which solution you choose.

As I think about this more, the idea of a QwtPlot widget inside a delegate might be feasible. The delegate -can- instantiate a single QwtPlot on construction and use that for all cells. That makes it much lighter weight than my current solution of a widget per cell.

My users do need to be able to edit by interaction with certain items contained in the plot, the the delegate can handle that by using it's QwtPlot instance as the editor. For normal painting, I can render the widget contents to an image and simply display that in the cell. I should be able to create that image and attach it to the model as user role data. (I'll ignore the fact that models can be shared among views for now). When the view resizes, I will need to recalculate and cache all of the visible images, but I need to do that now with the widgets anyway.

Thanks for all this useful discussion. It has allowed me time to think about the problem and use your answers to guide me to a better solution.