QtGui.QGuiApplication

[ababak]

QtGui.QGuiApplication is used to acces QScreen objects instead of the deprecated QDesktopWidget

[mottosso]

QGuiApplication doesn't exist in PySide/PyQt4, sorry. 😭
https://doc.qt.io/qt-5/qguiapplication.html

[ababak]

But we need it in PySide2/PySide6

[mottosso]

Sorry, Qt.py can't include anything that isn't in all bindings. You'll need to import PySide2 or 6 explicitly to access things that only exist there.

[ababak]

It's a pity. Qt.py is mostly used in transition periods. Now it's about migrating from PySide2 to PySide6. What's wrong with supporting objects for bindings where they do exist?

[mottosso]

Qt.py is designed to let you write software with one binding that works across all supported bindings. If we include things that only exist for part of them, then there would be no point in using Qt.py to begin with.

An argument could be made to deprecate PySide/PyQt4, as they are old and possibly no longer used. I've put this together to find out.

• Should we remove support for PySide/PyQt4? #413

[MHendricks]

For specific use cases you can customize what Qt.py exposes by defining a QtSiteConfig module. The examples link shows more complex configurations like adding a specific class in QtGui, but it's basically just editing the provided nested dict.

Note that this will make your code less portable but that may not be a problem for your use case. At my company we expose the legacy(in python) QVariant specifically for access to it's enums. We also expose the PyQt5 only QScintilla module, we can do this because we know our code only will be run using PyQt5.

That being said, you could look into adding a Qt.QtCompat workflow for providing uniform access to the features you are looking for/think would be useful. I know that I will need to eventually deal with updating our code that ensures that our saved prefs for window position don't result in the windows showing up offscreen due to monitor changes to work in Qt6.