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
Lets fix the Sphinx in-code documentation (Ignoring should never embed classes within other classes)
class FoldableDockWidget(QDockWidget): """ A simple Qt Widget that adds a 'minimise' button that vertically reduces the dock widget to just the titlebar to allow the dock widget to still take up minimal screen real estate """ class TitleBarWidget(QWidget): def __init__(self, title:str, parent:QWidget=None): """ We create a custom title bar using QWidget as the base. The title bar has to be wrapped in another widget so that its background can be styled easier, otherwise it's impossible to style :param title: the title to appear in the title bar """
Becomes
class FoldableDockWidget(QDockWidget): """ A simple Qt Widget that adds a 'minimise' button that vertically reduces the dock widget to just the titlebar to allow the dock widget to still take up minimal screen real estate """ class TitleBarWidget(QWidget): """Create a custom title bar using :py:class:`~PySide6.QtWidgets.QWidget` as the base. The title bar has to be wrapped in another widget so that its background can be styled easier, otherwise it's impossible to style :ivar title: the title to appear in the title bar :vartype title: str :ivar parent: Default None. Identify parent widget :vartype parent: PySide6.QtWidgets.QWidget | None """ def __init__(self, title: str, parent: QWidget = None) -> None: """class constructor"""
typing matters. Normally separate typing into stub files. The Sphinx in-code documentation includes typing, so the signatures can be simplified and easier to read
def __init__(self, title, parent=None):
Thanks for your response.
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.
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.If the user wanted to create a new
FoldableDockWidget
with a different title bar, they’d extend theFoldableDockWidget
class and override the Titlebar method in their extension of it. I understand your point, but isn’t it over optimisation?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!
Think the quote is
premature optimization is the root of all evil
. Don’t know who came up with that famous expression.In the case of the code in the process guard, perhaps you are right.
In the case of embedding a class within FoldableDockWidget, it’s simply a case of don’t do that, not optimization.
qasync
Python library for using asyncio in Qt-based applications
^^ is the package to support them all.
This comes directly from an app i wrote,
from qasync import (asyncSlot, QtWidgets, QtGui, QtCore, _make_signaller)
Here is some code which deals with differences between implementations
from qasync import (QtWidgets, QtCore, QtGui, QtModuleName) __all__ = ["QtportQAction", "QtportQScreen", "QtportQScreenImplementation"] try: QtportQAction = QtWidgets.QAction except AttributeError as e: #"PySide6", "PyQt6" QtportQAction = QtGui.QAction try: QtportQScreen = QtWidgets.QDesktopWidget QtportQScreenImplementation = "QDesktopWidget" except AttributeError as e: QtportQScreen = QtGui.QScreen QtportQScreenImplementation = "QScreen"
So it can be done!
In the case of this gist, it’s premature optimization. Generally it’s necessary cuz new implementations come along often.
That sounds terribly inexperienced. That’s exactly what updates to code are for. You cannot manage all kind of, sort of similar but different libraries with one code base. It would be horrific to even consider it.
The same argument can be made for supporting Windows and MacOS. Don’t have these dev environments. But somehow found a way to support these platforms.
If you look into it, pyQt[x] and pySide[x] aren’t all that different. The intent of PySide is to keep them for the most part compatible.
Don’t have to manage everything, just what is being used.
Doing the wrong thing explains most my packages:
wreck – dependency management
drain-swamp with drain-swamp-action – build backend with build plugins
logging-strict – strictly validated logging configuration
pytest-logging-strict – the same thing except a pytest plugin
What else am i not supposed to do?