Search code examples
c++qtqtableviewqtablewidget

QTableWidget vs QTableView

I am new to this Model/View Framework of Qt. In my application I want to have 1000 X 1000 cells. There should be minimum memory requirement & it should be fast. I don't know what this Model terminology is for. But I have my own class which knows how to deal with the double variables stored in the table. Currently I am using QLineEdit's with a Validator to create the array of cells. But it was way too slow for cells > 50 X 50. So I decided to go the good old MS Excel way.

So which Widget should I use: QTableWidget or QTableView?

And can anybody please explain in short what this Model/View framework is? I am not a Computer Science guy hence I am finding it tough to understand...

Solution

  • cmannett85's recommendation is a good one. Read the docs about a dozen times.

    Start with QTableWidget if your needs are pretty basic. QTableWidget is a QTableView PLUS a basic data model, built in. The table manages its own data.

    Then, if performance and memory issues are your primary concern and you think you can out-perform the QTableWidget implementation, then a QTableView interface on top of a QAbstractTableModel or QStandardItemModel is your best bet. QStandardItemModel combines the raw data and model into a single class, while QAbstractTableModel allows you to store your raw data separately from the model. Since you're new to Qt's model-view architecture, I'd recommend using the QStandardItemModel until you feel like you're getting the hang of it.

    If your performance still isn't good enough, avoid a lot of the memory duplication and wasted objects by implementing your custom model. Plus, get yourself a good textbook and read its chapter on the model-view framework about 12 times. That section alone was worth its weight in gold, imho.

    Here are the basics for Qt's custom model-view framework:

    • Your actual data is stored in a list/tree somewhere
    • The model provides a standard framework for queries to and edits for your data
    • Proxy models (optional) allow you to sort/filter your data without affecting the original model
    • The view provides a means to visually observe and interact with your data
    • Delegates (often optional) tweak the appearance of your data and provide custom editors to the data

    If you're feeling both cheap and brave, check out this excerpt on implementing your own custom model. Work at it one function at a time and play with it as you go.