I guess I don't see what you mean...I don't want to sidetrack you though. If you have a way that is working for you and fulfills all of your requirements then ignore me!
On Thu, Jun 5, 2014 at 11:11 AM, Marcus Ottosson <[email protected]> wrote: > The issue is that each item is unique. > > Treating all identically is perfect for situations like in your examples, > where each item fulfils identical tasks with varying data. Some items have > buttons, others have sliders, others 3d views. > > The issue relates to traversing a signal from an item with functionality > through an object without this functionality. Do you see what I mean? For > it to accept and forward the signal, it must know about it, which lies > outside of its responsibilities and breaks encapsulation. > > > On 5 June 2014 15:28, Tony Barbieri <[email protected]> wrote: > >> Hey Marcus, >> >> I understand about the lack of concern for performance. >> >> Off the top of my head, the way I would potentially deal with your >> scenario is I would have a single hierarchical data model then connect a >> single signal to the model that's triggered whenever the "run" command is >> requested. When the signal is fired I would get the currently selected >> index and then use the data the index refers to to get the required data >> that's necessary to react to the run command request. If you are using a >> single consistent hierarchical data model you shouldn't have to "bubble" an >> event all the way up, you'd have a "model object" that abstracts away the >> details of the internally stored data and allows the "controller" to handle >> any item type. >> >> Now for the view. This is going to be confusing, but the first "view >> column" would consist of the root rows of the data model then each "child >> view column" would be made up of the child rows of the parent row all the >> way down until you hit a leaf node. >> >> The view could also use the details of the internal data to decide how it >> should draw itself and present the data to the user. >> >> Right now it seems as if you are treating each item autonomously rather >> than considering all of the data as part of a single model which abstracts >> out the internal details. >> >> Not sure if that's useful at all...It's potentially how I would deal with >> it to avoid signal/event hell. >> >> >> >> On Thu, Jun 5, 2014 at 9:32 AM, Marcus Ottosson <[email protected]> >> wrote: >> >>> Thanks Tony, and I’m sorry for sounding like a broken record here, but >>> performance is of no concern to me. It isn’t that I don’t think performance >>> is less important, but rather that now is not the time. And, again, the >>> number of items in the mock-up I posted above is the mid-range of items >>> ever visible to a user at any point in time, and regular widgets have >>> proven more than capable of handling such low counts. >>> >>> Yes, it is working, but like I said, it’s difficult to maintain and so >>> I’m looking for alternatives - in design, not necessarily in >>> vendor-specific implementations. >>> Example time >>> >>> For the sake of argument, let’s consider the mockup above and have a >>> look at how the first item in the list, “Snake”, expands into another list >>> containing 3 main items; each of which is drawn differently. The top one >>> consists of additional items, each of which is also drawn differently. >>> >>> For me to click “run” and have that QPushButton signal to me that it is >>> “snake” signalling “run” from his “stats”, say, wouldn’t I have to >>> propagate a signal up through this hierarchy? >>> >>> /MillerView/Column1/snake/stats/run >>> >>> *Each of which has a corresponding path on disk. >>> >>> If “run” were to signal the model directly, what would it tell the model >>> in order to communicate this information? >>> >>> Best, >>> Marcus >>> >>> >>> >>> On 5 June 2014 14:04, Tony Barbieri <[email protected]> wrote: >>> >>>> 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 >>>> <https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsRvvMoim0M%2B%3DdCr4nkz%2B09amAqYcxj_bGeoP41dhXh68g%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/CAFRtmODS4dhDAaeD7x0wPMBAw1DFkC14QCwF6QnPgi_x3Us3Sg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODS4dhDAaeD7x0wPMBAw1DFkC14QCwF6QnPgi_x3Us3Sg%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/CAJhmvsQb4cN7xHG1vQ1%2BOKmroXkNrxpgOYe%3D%2BCEAeYm64wMLTw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsQb4cN7xHG1vQ1%2BOKmroXkNrxpgOYe%3D%2BCEAeYm64wMLTw%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/CAFRtmOAE4Qynq%3DvzapMnuZ8f0Piqf2bvibRJR7UpAUm%3DNiqJkA%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAE4Qynq%3DvzapMnuZ8f0Piqf2bvibRJR7UpAUm%3DNiqJkA%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/CAJhmvsTPNCEBhyWnOeAyyG0E6iSx%2BBw0fxXbppox06HV%3DxqLwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
