I’m working on a project that needs lots of toolbars on screen at once, even though not all of them will be used at the same time. So, I’m modelling this ‘foldable’ dock widget after what I remember Photoshop panels used to be like.

It’s a work in progress, but would like to hear constructive suggestions.

https://blocks.programming.dev/0101100101/42c5d67f86c049baa3500aa38e439f8a

  • 0101100101@programming.devOPEnglish
    2·
    3 days ago

    Thanks for your response.

    should never embed classes within other classes)

    Why is this? I have to admit that coming from other languages, it feels dirty, but is there a pythonic good reason for this? The class ‘belongs’ to the FoldableDockWidget class, so I figure it’s the best place to put it.

    • logging_strict@programming.dev
      2·
      3 days ago

      Arguing for modularity. Which isn’t likely in a gist (or a script), but is normal for a package.

      By embedding the class, creates a limitation that prevents abstractions or other implementations of each component. Imagine every suggestion in this conversation thread is another variation with a separate implementation.

      The widget class belongs to the FoldableDockWidget class until it doesn’t. Then a refactor is needed.

      There should be four modules. The entrypoint (and cli options parsing), the application, the dockwidget, and the widget. Each should be testable by itself.

      A widget is not a container. An application is not a container component (avoiding the word widget). Hardwiring a particular implementation of the Windowing Python wrapper is also unnecessary (PySide6). What about PySide2, pyQt5, pyQt6, and whatever else comes next?

      As a side note

      Why is there code in the process guard, besides main() (or a async equivalent)? Only multiprocessing applications have code within the process guard. Code within the process guard is unreachable; can’t be imported. For example, testing just the cli option parsing.

      • 0101100101@programming.devOPEnglish
        1·
        1 hour ago

        By embedding the class, creates a limitation that prevents abstractions or other implementations of each component. Imagine every suggestion in this conversation thread is another variation with a separate implementation.

        If the user wanted to create a new FoldableDockWidget with a different title bar, they’d extend the FoldableDockWidget class and override the Titlebar method in their extension of it. I understand your point, but isn’t it over optimisation?

        The widget class belongs to the FoldableDockWidget class until it doesn’t. Then a refactor is needed.

        One line of instantiating code. I can’t imagine where or how the custom title bar would be used outside of the Foldable Dock Widget class though. That’s probably the real reason why I made it a sub class. Not how I’d do it in other languages, but in Python? I’m trying it out!

        Hardwiring a particular implementation of the Windowing python wrapper is necessary. They have slightly different implementations. If something magically new comes along, then, the code is updated. Again, over optimisation here which is unnecessary.

        The code in the process guard is just sample code to demonstrate use of the class. No big deal. It’s separate to the class and not to be imported because… this is a gist of sample code!