Chart Model-View

Using Qt's Model-View

What are the pros and cons of using Qt's model-view to implement the charting widgets?

The main benefit of using Qt's model-view architecture is that is is already designed. This benefit can also be viewed as a stumbling block. Qt's model-view architecture is a little complicated. Unwanted behavior can be built in too. Qt uses private classes to do much of the work. These private classes make it difficult to override behavior. I ran into this a few times when building the flat tree view. The selection highlighting is still unresolved. Qt doesn't honor all the item flags when selecting items. Items can be made the current item even if they are not selectable.

--Mark Richardson 19:03, 10 Aug 2006 (EDT)

Another pro for using Qt's Model-View is that, when appropriate, we can use the same model with chart widgets and widgets that come with Qt. For example, if the x-y plot chart accepted values in a Qt model 2 column table, that same data could be put in a QTableView, which could be handy. If we were able to use the Qt selection classes, the selection could be easily linked, too.

--Ken 09:16, 11 Aug 2006 (EDT)

Qt views always ask for the data as a string. The call will convert a number to a string, but doesn't give us an option of how to convert it. We would have to make our own delegate class to be able to format the numbers how we want them. The delegate could most likely be derived from Qt's concrete delegate class to provide most of the functionality. This isn't a show stopper, but something to be aware of.

--Mark Richardson 11:49, 11 Aug 2006 (EDT)

Creating a New Model-View

What are the pros and cons of creating a new model-view architecture for the charting widgets?

Building our own model-view architecture will take time. It's unclear which path will take less time though. The main benefit of designing our own architecture is that it will behave exactly how we want it too. The interface can be tailored to fit PGraph. I think we can make the interaction between the model and the view simpler than Qt's without losing any functionality. The models in Qt are nice and simple, but the views are a little tangled. Our own design can be made more efficient than Qt's implementation as well.

--Mark Richardson 19:03, 10 Aug 2006 (EDT)

Another reason to write our own is the model complexity. The histogram widget has two layers: a histogram and a line plot. The two plot types share the bottom axis and use their own vertical axis. The Qt model would have to look something like:

root
  + Histogram
  |   + Values
  |   |   + 1, 12, 5, etc.
  |   + Range
  |       + min, max
  + Line Chart
      + Line1
      |   + x1, x2, etc.
      |   + y1, y2, etc.
      + Line2
          + x1, x2, etc.
          + y1, y2, etc.

We would need to make a special subclass of Qt's model in order to ensure the data was formatted correctly. The model would not be easily viewed by other Qt views. We would need special code to get the correct root to display in the view. There would be a small sliver of time that the root would be the model root before it could be set to the correct root due to the way Qt handles this. It would be cleaner to have a custom model for other views that would just show the relavent portion of the larger model. It could even be used to combine two lines into one model.

Qt would also expect each piece of the model to be rendered. What would that mean for the axes? How would selection interact with the model? Using single selection, we would only be able to select one index, say x1 of line1. How would that look on the chart? we would have to use multiple selection to select x1 and y1 to select an entire point. The selection model would be difficult to use by other components in the system. We could combine the coordinates into one index, but then everyone needs to know about the special data type. The view would not be able to use the model's data() method to get the data. It would have to get the data in a special way. The same would be true of any component using the selection model.

The Qt model data type is qvariant, which allows for more types than the chart can render. Our model subclass would have to restrict what types are set.

All these complications in using the Qt model could be avoided by writing our own.

--Mark Richardson 17:16, 11 Aug 2006 (EDT)

This case is the show-stopper for me on using QAbstractItemModel - while a hierarchy of tables can be used to represent chart data, the meaning and relationships of each table are implicit rather than explicit. I'd rather see custom model classes (pqLinePlotModel, pqHistogramModel, etc), which are as consistent with QAbstractItemModel as possible, but no more. Where tabular data is required, adapters can be written to make the custom model classes compatible with QAbstractItemModel. Tshead 15:18, 14 Aug 2006 (EDT)

I think it is important to differentiate between data and how it is displayed. The data coming from VTK (vtkTable, vtkRectilinearGrid etc.) can be represented by a Qt model. This model can then be viewed by a table widget without any changes. It sounds like the difficulty is in representing the properties of a graph or a histogram with a Qt model. I think that these properties should be separated from the model because they are specific to the way the data is viewed not the data itself. The range used in a graph or the color of cells in a histogram are not properties of the data but the graph or the histogram. We will need separate server manager objects to represent these (so that they can be shared with python and saved in state) and we will need Qt-side representation. Maybe plot property model and histogram property model? Berk 10:27, 22 Aug 2006 (EDT)