Hey, The QAbstractItemModel speaks in terms of QModelIndex as a way to communicate between any implementations of QAbstractItemView, regardless if the view is a single column, a table, a tree, or some other abstract representation. You can't really avoid it as it is part of the interface. But that doesn't really impact your data. The difference between something like QStandardItemModel (or even QTableWidget for that matter) is as you said, performance and control. You can do perfectly fine with a QTableView (or the like) to a certain extend. But there are a few different circumstances I have run into that make the abstract model a better choice:
* You have a ton of data and it becomes to slow to show it in a higher level widget * You have lots of updates happening in your model/data and the update frequency is slow in performance * You have a completely custom data source that you want to represent without having to deal with the item-based approach So when you make an Abstract model subclass, you can store your actual data however you want (or not store it and just source it from where ever) and you are obligated to implement a few methods if it is read only, or a few more if it is a writable model, in order to make it compliant with the qt views that are available. You are just telling it how to resolve back and forth from a QModelIndex, and how to resolve various types of data for different roles. I recently just had a view in my app that was originally written quickly with a QStandardItemModel and a QTableView. The process of putting data into the model and updating it meant creating QStandardItem types, and populating it with possibly duplicate data, and putting it in and out of the model. What you don't get with this approach is the granularity of controlling how and when the model notifies the view about updates. You get some, but not as much. So once I had over about 500-600 items in this view, doing the things it did, it became ridiculously slow. Like unusable. Updates on the view would take easily over 5 seconds. I finally got the time and rewrote it using a QAbstractItemModel subclass, where my data was all stored internally and I no longer had to deal with creating many QStandardItems for each cell. My update times went down into 50-150ms when my data was around 750 items (which is actually quite a lot for the particular use and is more of an edge case). But for those people that were using it with that much data it is now useable and really quick. The downside is that it is more complicated to use the abstract models. They are prone to getting wrong. I have found that using the PySide port of ModelTest works really well to help validate that you have written the model correctly. If you get some stuff wrong, you end up with funky behavior. Anyways, I am still perfectly happy to use the higher level widgets when the data set is reasonable, or the widget is transient. But when I know it has to deal with a ton of data, or data that is changing very frequently, I get more control of updating the abstract model subclass in batches so the view ends up doing a lot less redundant updating and responding. -- justin On Thu, Jun 5, 2014 at 8:09 PM, Marcus Ottosson <[email protected]> wrote: > Hey guys, > > I've decided that the work involved in transitioning to QAbstractItem* is > overwhelming and might cause me to miss my deadlines. It's possibly > something for a 2.0 (assuming QAbstractItem* it is a better suited > solution). > > For reference, here are some of the things consuming time. > > I couldn't figure out how to get QAbstractItemModel to work without > involving QModelIndexes, which is ok. However, QAbstractItem*View* is > also dependent on QModelIndex, which means deriving anything custom would > involve adapting QModelIndex here as well, not to mention its separation > between selection models and delegates. Overall, it is my impression that > the QAbstractItem* family is designed to enable very large data models, > which isn't what I'm looking for. > > As I've built my views and have a working prototype, I can either get with > it or tear it down and start over, which like I said would put my schedule > at risk. > > Not sure what you guys would do, but to me it seems a perfectionist issue > (again, assuming QAbstractItemModel is the perfect candidate) > > Thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODzSVxGxxgB2BKitoKs3_itn9N5dizRWdi7%2BmYwMHuFAQ%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODzSVxGxxgB2BKitoKs3_itn9N5dizRWdi7%2BmYwMHuFAQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3zhXd0-vC8UQCF-kR8n%2BVmk3yzEeMh7RQ%2B68TL0sAEBQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
