Description
I wonder on which platform screen number maps to something useful?
Seems like unnecessary burden to maintain and allows people to write non-optimal code, e.g:
QPoint pos;
int screenNr = QApplication::desktop()->screenNumber(p);
QRect geo = QApplication::desktop()->screenGeometry(screenNr);
when a cleaner way exist (I have seen the above pattern in many places):
QPoint pos; QRect geo = QApplication::desktop()->screenGeometry(pos);
Why have:
QDesktopWidget::availableGeometry QDesktopWidget::screenGeometry
When we can add methods returning QScreen:
QScreen * QDesktopWidget::screen(const QPoint &p) const QScreen * QDesktopWidget::screen(const QWidget *widget) const
enabling developers to call ::availableGeometry() / ::screenGeometry() directly on QScreen? This gives access to more meaningful screen identifiers (compared to arbitrary screen numbers) - QScreen::model(), QScreen::name().
With these changes QDesktopWidget API would become very minimalistic (without loosing any of existing functionality), thus it might make sense to deprecate the whole class and move this tiny API over to QGuiApplication, which already has QScreen related methods, such as - ::primaryScreen(), ::screenAdded(), ::screenRemoved(), ::screens().
Furthermore, QDesktopWidget is a QWidget sub-class, so having this API in QGuiApplication would make it accessible to QML without widget dependency.
Bonus is that we could cleanup our code in various places from checks like ( .. != Qt::Desktop ), as it was necessary for QDesktopWidget purposes-only AFAICT.
Attachments
Issue Links
- relates to
-
QTBUG-69410 Qt Widgets Changes in Qt 6
- Closed
-
QTBUG-50788 QApplication::desktop()->screenNumber returns wrong screen during startup
- Reported
-
QTBUG-72819 SplashScreen shown on wrong monitor, scaling is incorrect
- Closed
- resulted in
-
QTBUG-76162 When using separate dual displays (no Xinerama), menus will popup on display 0 even if the parent is on display 1
- Closed