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. For more options, visit https://groups.google.com/d/optout.
