> > Are you using QAbstractItemModels or the Qt “MVC” framework? > >
Could you clarify this? Is QAbstractItemModel not part of their MVC > framework? Yes it is part of the MVC framework, sorry about the confusion :). I couldn't figure out how to get QAbstractItemModel to work without > involving QModelIndexes, which is ok. You won't be able to use QAbstractItemModel without using QModelIndexes. QModelIndexes are important when working with the Qt MVC objects. Justin's summary of when/why to use the MVC framework is great. From what I can tell about the tool you're writing, looking to port it to using the MVC framework in the future may be worth it as it seems like you are using project data which can end up growing quite large. I had done a similar approach to what you are doing (using the high level widget objects) on some of our project tools in the beginning but once a few projects started up that had higher data requirements (hundreds of entities) it fell flat on it's face and I had to scramble to convert it over to using Qt MVC so we could get usable performance. I also still use the higher level widget's, but it depends on the tool I'm writing. Some things are better off using the MVC framework, although the barrier to entry with using it is a lot higher. Once you wrap your head around a few of the concepts though, it becomes a lot easier to manage. I recommend looking into it when you have some time, some of your tools may benefit from it. In the end if you have it working and it meets your requirements, take everything I say with a grain of salt :). On Thu, Jun 5, 2014 at 7:45 AM, Marcus Ottosson <[email protected]> wrote: > Thanks Justin, that makes sense. > > However like I said, I'm not interested in performance, nor do I have that > many objects in a view at any point in time. For such things, I would > certainly go for QAbstractItem*. > > > On 5 June 2014 10:54, Justin Israel <[email protected]> wrote: > >> 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 >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3zhXd0-vC8UQCF-kR8n%2BVmk3yzEeMh7RQ%2B68TL0sAEBQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *Marcus Ottosson* > [email protected] > > -- > 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/CAFRtmOBUy5u_v1Co992DHu9p%3DCB8OKbnFMk77yUU6y-niRxwGQ%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBUy5u_v1Co992DHu9p%3DCB8OKbnFMk77yUU6y-niRxwGQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Tony -- 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/CAJhmvsRvvMoim0M%2B%3DdCr4nkz%2B09amAqYcxj_bGeoP41dhXh68g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
