One thing, what about widgets in the path leading up to the global handler, what if they want to do something with the event before passing it along?
On 6 June 2014 09:52, Marcus Ottosson <[email protected]> wrote: > That looks great, Justin. Thanks for that. I'll play around with this and > see if it fits. > > > On 6 June 2014 09:45, Justin Israel <[email protected]> wrote: > >> BTW, sorry but I converted your example to PySide since I didn't have Qt5 >> handy. It was a minimal change. Just some imports and a type convert for >> the event types. >> >> >> On Fri, Jun 6, 2014 at 8:44 PM, Justin Israel <[email protected]> >> wrote: >> >>> I did already look at your example earlier. I just didn't get a chance >>> to run it and examine it in detail. It doesn't really have anything to do >>> with the other side of the discussion with models and what not, so >>> obviously lets completely forget that part. >>> >>> I wrote a variation for you that is using an event filter approach: >>> http://pastebin.com/Rn739jdA >>> >>> In this version, all of the logic is moved into a "handler" or >>> controller. Whichever you want to call it. But you would install the event >>> filter on the target widgets and it can do whatever centralized logic that >>> you want. Maybe this is of interest or maybe it is completely off from your >>> goal. But either way, I thought it might be nice for the discussion to >>> introduce the example that illustrates the event filter approach. Always an >>> option. >>> >>> >>> >>> >>> On Fri, Jun 6, 2014 at 7:47 PM, Marcus Ottosson <[email protected]> >>> wrote: >>> >>>> Ok, before we go any further, I suggest you have a look at my example. >>>> I believe what you are suggesting is what has already been done. >>>> >>>> >>>> On 6 June 2014 08:15, Justin Israel <[email protected]> wrote: >>>> >>>>> >>>>> On Jun 6, 2014 5:42 PM, "Marcus Ottosson" <[email protected]> >>>>> wrote: >>>>> >> >>>>> >> If you are doing Miller columns then that should be equivalent to >>>>> multiple views of the same data. Presumably you are modeling a path >>>>> hierarchy and each column is a view onto a different level of the same >>>>> data >>>>> model (presumably). Doesn’t really matter but I just thought to mention >>>>> it. >>>>> > >>>>> > Not sure I’m following you here. Are you saying that: >>>>> > >>>>> > data = ['item1', 'item2', 'item3'] >>>>> > >>>>> > model = MyModel() >>>>> > model.setup(data) >>>>> > >>>>> > view1 = MyView() >>>>> > view1.setModel(model) >>>>> > >>>>> > view2 = MyView() >>>>> > view2.setModel(model) >>>>> > >>>>> > Is the same as.. >>>>> > >>>>> > data = ['item1', 'item2', 'item3'] >>>>> > >>>>> > model1 = MyModel() >>>>> > model1.setup(data) >>>>> > >>>>> > model2 = MyModel() >>>>> > model2.setup(data) >>>>> > >>>>> > view1 = MyView() >>>>> > view1.setModel(model1) >>>>> > >>>>> > view2 = MyView() >>>>> > view2.setModel(model2) >>>>> > >>>>> > ..due to both of them using the same set of data? I assumed what you >>>>> mean with multiple views onto the same set of data involved using the same >>>>> model, and having them both update according to it, rather than meaning >>>>> that the file-system is some sort of model. >>>>> >> >>>>> >>>>> No those are two different views using two different models. I am >>>>> talking about the first one, where a single model represents the state of >>>>> things and different views can root at different levels of it and respond >>>>> to the same changes in one place. This would be opposed to loading two >>>>> models with duplicate data. In a Miller column I figured you were showing >>>>> the hierarchy of a filesystem or file content meaning it is all the same >>>>> data source which could use the same model, but with different list views >>>>> showing different parts of the model >>>>> >>>>> >> Event filtering means you can tell one object to receive all events >>>>> first for a given QObject subclass. It can choose to do something based on >>>>> the event and/or decide whether the event should continue to reach the >>>>> original target. That means you could have logic all in one class that >>>>> chooses to do things for other objects like when the mouse is pressed. >>>>> > >>>>> > Yes, in my example this is what is happening, but without event >>>>> filters. My question is, what would event filters do differently? >>>>> > >>>>> > >>>>> >>>>> In the event filtering approach you would need a custom subclass to >>>>> use as a baseclass for all your widgets. You would have one class that can >>>>> look at an event and decide what to do with the object and then install it >>>>> as an event handler on any widget that needs it. >>>>> >>>>> >>>>> > >>>>> > >>>>> > On 5 June 2014 23:12, Justin Israel <[email protected]> wrote: >>>>> >> >>>>> >> If you are doing Miller columns then that should be equivalent to >>>>> multiple views of the same data. Presumably you are modeling a path >>>>> hierarchy and each column is a view onto a different level of the same >>>>> data >>>>> model (presumably). Doesn't really matter but I just thought to mention >>>>> it. >>>>> >> >>>>> >> Event filtering means you can tell one object to receive all events >>>>> first for a given QObject subclass. It can choose to do something based on >>>>> the event and/or decide whether the event should continue to reach the >>>>> original target. That means you could have logic all in one class that >>>>> chooses to do things for other objects like when the mouse is pressed. >>>>> >> >>>>> >> On Jun 6, 2014 9:48 AM, "Marcus Ottosson" <[email protected]> >>>>> wrote: >>>>> >>> >>>>> >>> Thanks Justin. The code example above is using custom events, and >>>>> I think it should do what I'm looking for, but I won't know for sure until >>>>> tomorrow once i've integrated it. >>>>> >>> >>>>> >>> As for event filters, don't have much experience with those, but >>>>> do you think they would allow for the same thing? Without or with custom >>>>> events? >>>>> >>> >>>>> >>> And finally, multiple views is fancy but are not important in this >>>>> situation. If that was a requirement, I would definitely go for separating >>>>> the model. >>>>> >>> >>>>> >>> Ultimately, I believe that my requirements are low, that there is >>>>> a straightforward solution, and that throwing pre-packaged widgets or >>>>> QAbstractItem* at the problem is only escalating things. >>>>> >>> >>>>> >>> Looking forward to your thoughts on the example, I find it nimble >>>>> and complete, more sophisticated than what I've got going on currently and >>>>> mainly simple and easy to communicate to others with minimal knowledge of >>>>> Python. >>>>> >>> >>>>> >>> Best, >>>>> >>> Marcus >>>>> >>> >>>>> >>> On Thursday, June 5, 2014, Justin Israel <[email protected]> >>>>> wrote: >>>>> >>>> >>>>> >>>> I wouldn't call it a magic bullet either. They are more >>>>> complicated to set up for sure. But they do work well in situations where >>>>> you have multiple views on the same data. I've done the Miller Column >>>>> thing >>>>> both using the built in QColumnView, and also setups that use the vertical >>>>> layout with custom widgets, like you are doing. The QColumnView is pretty >>>>> much a bunch of list views in a horizontal scroll that have their root >>>>> item >>>>> set to different levels of the same model. So multiple views share the >>>>> same >>>>> data. In the case of the custom widgets in vertical layouts, when I have >>>>> done stuff like that, I have usually given the "run" button equivalent the >>>>> context it needs to use when the click happens. Like giving it a >>>>> prewrapped >>>>> callback that it does not have to know about. But you obviously know at >>>>> the >>>>> time of its creation that it has a context. >>>>> >>>> >>>>> >>>> But ya lets just leave the whole model thing aside because it is >>>>> a drastic mental shift than what you are already doing. Always something >>>>> that can be played with later. I can try and take a more focused look at >>>>> your code example tonight, but it does seem like something could be done >>>>> with an event filter or customEvents. Ultimately as long as you get some >>>>> sort of mechanism that pushes events up the chain, you would be good. I >>>>> wasn't clear on the part where you said you didn't want to overload the >>>>> event() method since you weren't sure of its logic. But I would think you >>>>> could still do that and perform save operations, and then call the >>>>> original >>>>> event handler at the end. >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> On Fri, Jun 6, 2014 at 7:51 AM, Marcus Ottosson < >>>>> [email protected]> wrote: >>>>> >>>>> >>>>> >>>>> 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 Programmi >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>> >>>>> >>>> >>>>> >>>> -- >>>>> >>>> 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/CAPGFgA3gR-mwQBc7Q1L25GAcajvoJ2VeRA6oQAXkiP8ZrNABmA%40mail.gmail.com >>>>> . >>>>> >>>> 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/CAFRtmOBAYw%2BLNYEqUsoFEtttMyEKctNoCsPXv9Vbyyp-wrbaiA%40mail.gmail.com >>>>> . >>>>> >>> >>>>> >>> 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/CAPGFgA2Qk6wJ41qzUymzxLTTJQuSp%2BXxLJ7W9VwkFk8mUmPemw%40mail.gmail.com >>>>> . >>>>> >> >>>>> >> 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/CAFRtmOC4mxs67k6HMYGJ5AOPKORo4C1jDbfofgLFQbcXnFoY2Q%40mail.gmail.com >>>>> . >>>>> >>>>> > >>>>> > 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/CAPGFgA209ZfdtcpKvYD859-NksH1F8vs9DS%3D%3DoW9Yi2PuoYeBQ%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA209ZfdtcpKvYD859-NksH1F8vs9DS%3D%3DoW9Yi2PuoYeBQ%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/CAFRtmODeaBzZSSNw_b_o3KNaDk03YojnBs9Q523pgKzP%2BNAH2A%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODeaBzZSSNw_b_o3KNaDk03YojnBs9Q523pgKzP%2BNAH2A%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/CAPGFgA3XHidSdrqdZCNO0As7wtx2pu236Dg8oaNxG%2B0Pju%2B6_g%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3XHidSdrqdZCNO0As7wtx2pu236Dg8oaNxG%2B0Pju%2B6_g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *Marcus Ottosson* > [email protected] > -- *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/CAFRtmOBGPF9uNH0HzbgFUy%3D9J299MJ%3DKPT-c12-hmX2QvMDZVQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
