Well, the general issue I see with the QAbstractItem* family is its complexity and that it seems better suited for massive datasets, for which I suspect it was designed.
I believe it can be simpler if datasets aren't as large. (less than hundreds of items) If you have a look at the example I just posted, can you see where such a model would fail and where a QAbstractItem* approach would make it easier to maintain? Even if we disregard the low count in items, and disregard performance, can you see anywhere where this model would stop making sense? I'm trying hard to KISS, QAbstractItem* isn't simple enough. I really don't think it's as much of a silver bullet as it you're making it out to be. On 5 June 2014 20:44, Justin Israel <[email protected]> wrote: > Yea sorry. Apparently I don't get it either. I was following Tony's reply > and it made sense to me but I suppose was not applicable to you? I also saw > it as a situation where child items in a model know their own context and > their parent item. So when representing the "run" item, it knows the > context of it being a "run command for snake within the stats location" > because it all shares the same underlying data to know that. The fact that > it is a button with a signal is part of the view/delegate aspect. A custom > data role could give you back the "context" object that you need for the > view or delegate to perform the action in response to the click. > Again, like Tony, I apologize if this sounds complicated or abstract. It > still doesn't click for me that it needs to be a massive signal passing > situation. Only so if you are purely working with widgets that are nested > and don't know about each others logic as opposed to a model that already > knows all the data in one place. > The performance and data aspects of the model aren't just about what is > currently visible. It is also about all the data that is know but not > visible. Like if you are modeling a filesystem, you may not be in a > location viewing a ton of files and directories, but that doesn't mean the > model couldn't resolve sibling or child directory listing ahead of time and > have extra data available. Or that you could resolve info about parent > locations that may not be displaying the data in a view, but have the data > available in the model (like the listing of a directory for which you had > just browsed through while navigating down). > I can see why in this situation you would need to pass a lot of dynamic > signals, when widgets are completely autonomous. If you are sticking with > that approach then it might be good to keep trying that customEvent > propagation technique that people list online, and seeing if you can get > it to work. Your custom widgets would probably have to have a customEvent > method implemented to handle the event if they want. The manual propagation > method you found gets around that need by continuing to drive it up the > chain until someone handles it. I'm not sure off hand but maybe the > customEvent default implementation accepts the event. > On Jun 6, 2014 3:40 AM, "Marcus Ottosson" <[email protected]> wrote: > >> I'm making an appearance here too. >> >> http://stackoverflow.com/questions/24064422/traverse-events-through-hierarchy-of-unique-widgets >> >> >> On 5 June 2014 16:38, Marcus Ottosson <[email protected]> wrote: >> >>> Aw. :'( Ok, thanks again for sticking with me this long! >>> >> >> >> >> -- >> *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/CAFRtmOA7Zp%2BOo74dB_xWmyLL_A6E%2BUjsVLFk9BGdAfor1Ww9Sw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA7Zp%2BOo74dB_xWmyLL_A6E%2BUjsVLFk9BGdAfor1Ww9Sw%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/CAPGFgA2FdDYWO%3DscvYSpy8ACrig%3D9sdBupdg_wSRo_g1r1PkLw%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2FdDYWO%3DscvYSpy8ACrig%3D9sdBupdg_wSRo_g1r1PkLw%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/CAFRtmOCLF5dCi%3DPmE1ZKGOttM5dn3HqHCX0PXww5HHRdoFMBXg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
