Using a different abstraction layer, includes Qt.py

[tobkum]

Not really an issue, but probably stupidity on my part - how do I use qdarkstyle when using Qt.py (https://github.com/mottosso/Qt.py) as a wrapper for Qt?
I migrated my project to Qt.py to be more flexible, but am having a hard time with getting the style back.
Thanks!

[dpizetta]

Hi @tobkum, it should be possible to use.

Using QdarkStyle v3.0
Actually, if you don't matter to add QtPy (not Qt.py) dependence (QDarkStyle v3.0), the style that you get is dependent on it. Both are not bindings, they are abstraction layers if I'm correct, so if you set both (qtpy and Qt.py) to the same binding, e.g., PyQt5, you can use the returned style to set your app. After you import, for example, qtpy.QWidgets, then print all imported packages you will see PyQt5.QWidgets (if you are using this binding).

Using QDarkStyle v2.x
Following the same arguments, you can check the version of binding you are using, then get the style according.

Creating a new option (for version 3.0, preferably)
Another option is to write another option in the QDarkStyle to use Qt.py - it should be also simple, take a look at the code dependencies.

Final thought
The style itself is a string, so it is not dependent of any binding. The real need to use it is to pre-compile and for problems, if mac-os when you need to add some more code.

Can you take a look at the first two options and check if it works? Tks :)

[tobkum]

@dpizetta Thanks so much for the suggestions! I'll try it over the weekend and report back :)

[tobkum]

I'd like to create a new option for compatibility with Qt.py and submit a PR - is the current head the v3.0 you're talking about or does that reside in an extra repository?

[dpizetta]

Hum, I think it would be nice to have one more abstraction layer possible, what is your option @ColinDuquesnoy ? The v2 we are just providing bugfixes. New stuff in v3. Tks

[ColinDuquesnoy]

I don't think we need to support more shim. It should not matter to client code which shim we're using as long as we clearly documents how the qt binding will be selected (e.g. set the QT_API environment variable). Client code is free to use whatever shim they want as long as they select the same qt binding. Most shim (maybe not Qt.py) support selection via the QT_API environment variable, so setting it once should be enough....

[dpizetta]

So, @tobkum adding my arguments and the @ColinDuquesnoy arguments, it is better we provide theQdarkStyle with QtPy, and since you set both Qt.py and QtPy, your app will run perfectly. Closing this issue. Thank you for your suggestion. We will add some advice for this configuration in the future.