Critique This! A Simple Qt Dock Widget which enables the whole widget to be 'folded' to use less screen space

0101100101 · 9 days ago

Critique This! A Simple Qt Dock Widget which enables the whole widget to be 'folded' to use less screen space

0101100101 · 5 days 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!

logging_strict · edit-2 5 days ago

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.

Hardwiring a particular implementation of the Windowing python wrapper is necessary.

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.

0101100101 · 4 days ago

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.

logging_strict · edit-2 3 days ago

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?