> There are examples online about how to get custom QEvents to automatically propagate up the parent hierarchy until someone handles it or it falls off. The same as built in QEvents.
I'm looking to test this out, but it seems that custom events aren't actually propagated the same as built-in events; On 4 June 2014 07:25, Marcus Ottosson <[email protected]> wrote: > Thanks guys, good thoughts. > > I had initially worked with QAbstractItem* classes but found them to be > working against me in this particular instance. Of course, this could also > mean that I don’t understand it well enough to make it work for me, but I > figure at one point or another I’ll have to take a beat, make an assessment > and move on. Hard to tell whether or not there was something I missed, > maybe I’ll put up another thread with specifics. As a side-note; I have > built several UIs with that implementation and overall find it amazingly > over-engineered, but that’s another topic altogether. > > About MVC; as I originally worked with the QAbstractItem* family, this was > unavoidable. But I felt part of what made those classes fail me was partly > due to their separation of concerns. Again, I can’t be sure whether I > understand it well enough, but from my experiences it wasn’t fit for this > purpose. Suffice to say I have considered these alternatives. > > QEvents on the other hand. Admittedly, it took me a while to wrap my head > around the difference between signals and events in Qt. Events is what I’m > using currently in place of signals for things such as this, but not QEvent > in particular. > > The reason for not using QEvent is that I have objects communicating that > lie outside of the graphical domain; i.e. classes not using Qt. What I am > looking at however is pypubsub <http://pubsub.sourceforge.net/> which is > a wxPython-inspired implementation of event-handling. It’s different from > Qt in that it does introduce globally accessible names (called topics, like > with messaging), but I’m too early in to make an educated guess about > whether or not it promotes bad design. The idea is to study it, evaluate > it, and ultimately port it to ZMQ and unify events across the system. > > Finally, on the topic of qtpath, the reason I’m looking to distil paths > into strings is so that I can send snapshots about the whereabouts of an > item within a hierarchy and from their make use if it and its neighbours. > Consider this. > > /Win.QWidget/Body.QWidget/John.QWidget > > From here, I can browse it’s members, similar to a folder on disk. > > John.QWidget > Name.QLineEdit > Age.QSpinBox > Address.QTextEdit > > And with that, I can design hierarchies based on how I’d like to organise > and access data. Like I would on a file-system. > > Let me know what you think. > > Best, > Marcus > > > > On 3 June 2014 23:10, Justin Israel <[email protected]> wrote: > >> >> >> >> On Wed, Jun 4, 2014 at 9:35 AM, Marcus Ottosson <[email protected]> >> wrote: >> >>> Ah, but I believe you’re missing the bigger picture. >>> >>> Files and folders have absolute paths and we can reference them. But of >>> course, coding anything to absolute paths is no good and I believe the same >>> is true for object hierarchies. With files, we develop resolvers and >>> expression to help decouple them from their roots; I believe the same could >>> be true for object hierarchies. >>> >> Ah but I am not really talking about trying to create an abstraction that >> is consistent with a filesystem. I am only talking about designs in Qt >> application, where as far as I know it can be a poor habit to maintain so >> much global knowledge across widgets about all of the hierarchies and >> composed children of widgets. >> >> >>> The problem with directly referencing anything is the spaghetti of links >>> you get between objects operating on other objects. >>> >>> The need arose when working with many widgets composited within other >>> widgets (think ItemViews) and where each item needed to signal an event up >>> through a hierarchy. To keep everything perfectly decoupled, it made sense >>> to not introduce a global variable or singleton and have each level instead >>> receive a signal and forward it to its parent until eventually being >>> handled by the topmost parent. Simple in theory. >>> >>> In theory, theory and practice are the same. In practice, they are not. >>> - Albert Einstein >>> >>> What ends up happening is that whenever you introduce another widget >>> in-between two widget, you’ll have to pick up those signals and forward >>> them to the next, and so the story goes. Changing anything was a nightmare. >>> To borrow terminology from Chad, it’s quite the PITA. >>> >> Are you sure signal/slots are the right tool for the job in this case? If >> your focus is trying to create a deep connection of signal propagation all >> the way up, maybe there is a better way involving custom QEvents or using >> an event filters? There are examples online about how to get custom QEvents >> to automatically propagate up the parent hierarchy until someone handles it >> or it falls off. The same as built in QEvents. >> >> >>> With qtpath, my thinking is that logical hierarchies can be decoupled >>> from their physical hierarchy, in that widgets with no objectName are >>> skipped during traversal. That way, programmers can design a hierarchy they >>> wish to program against, regardless of any hierarchy Qt enforces upon you >>> (e.g. QScrollArea having multiple unexpected children). >>> >>> # Reference `button`, even though there may be multiple levels of unnamed >>> parents inbetween. >>> $ /root.QWidget/button.QPushButton >>> >>> As for your example, of two object names being identical, this is >>> something I would consider poor programming effort and I’d entrust >>> programmers to not get themselves in such a situation. >>> >> It is only poor programming if your qtpath depends on objectNames being >> unique and breaks because of that assumption that they should be unique at >> all times. It is apparently perfectly legal to name two QWidgets the same >> object name and apply a CSS style to the id. >> >> >>> 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/CAFRtmOCWBbt%3DRNz2TMiehsHJCtWoSnF2zU7OCsYGpt3qXdCQDg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCWBbt%3DRNz2TMiehsHJCtWoSnF2zU7OCsYGpt3qXdCQDg%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/CAPGFgA1j05Desyg208FvP0NLzN0PNWd%3DHbg1KfpYaw5tsLJVzA%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1j05Desyg208FvP0NLzN0PNWd%3DHbg1KfpYaw5tsLJVzA%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/CAFRtmODZUJ6tJ0jjtrxOc8tG5qjRoptK-hfZy5FNUfhpCOUktg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
