Fixes #11207
This still obviously needs to be confirmed as the cause of the issues in question, this is the current assumption
Fixes #11207
This still obviously needs to be confirmed as the cause of the issues in question, this is the current assumption
Tagged for backport in case there will be another rc
utACK 7765030
861 | - if ((!pos.x() && !pos.y()) || (QApplication::desktop()->screenNumber(parent) == -1)) 862 | - { 863 | - QRect screen = QApplication::desktop()->screenGeometry(); 864 | + 865 | + QRect screen = QApplication::desktop()->screenGeometry(); 866 | + if ((!pos.x() && !pos.y()) || pos.x() > screen.width() || pos.y() > screen.height() || (QApplication::desktop()->screenNumber(parent) == -1)) {
How about
if (!screen.contains(parent->geometry()) || QApplication::desktop()->screenNumber(parent) == -1) {
And I think the first condition is enough, not sure though.
parent->geometry() does not include the window frame, so perhaps frameGeometry()? But yeah I guess a check for full containment makes sense rather than just the point pos()
856 | @@ -857,10 +857,9 @@ void restoreWindowGeometry(const QString& strSetting, const QSize& defaultSize, 857 | 858 | parent->resize(size); 859 | parent->move(pos); 860 | - 861 | - if ((!pos.x() && !pos.y()) || (QApplication::desktop()->screenNumber(parent) == -1)) 862 | - { 863 | - QRect screen = QApplication::desktop()->screenGeometry(); 864 | + 865 | + QRect screen = QApplication::desktop()->screenGeometry();
Use availableGeometry().
Yep sounds good. I'll fix it to availableGeometry(screen_number) too now that I think about it. Will push it as a separate commit for review before squashing.
Concept ACK.
I believe this was fixed here : #10156
856 | @@ -857,10 +857,10 @@ void restoreWindowGeometry(const QString& strSetting, const QSize& defaultSize, 857 | 858 | parent->resize(size); 859 | parent->move(pos); 860 | - 861 | - if ((!pos.x() && !pos.y()) || (QApplication::desktop()->screenNumber(parent) == -1)) 862 | - { 863 | - QRect screen = QApplication::desktop()->screenGeometry(); 864 | +
Remove whitespace.
862 | - { 863 | - QRect screen = QApplication::desktop()->screenGeometry(); 864 | + 865 | + int screen_number = QApplication::desktop()->screenNumber(parent); 866 | + QRect screen = QApplication::desktop()->availableGeometry(screen_number); 867 | + if ((!pos.x() && !pos.y()) || screen_number == -1 || !screen.contains(parent->frameGeometry())) {
If I understand correctly, !pos.x() && !pos.y() should be replaced with !settings.contains(strSettings + "Pos").
Safer to check after converting it to a point, just to make sure conversion worked properly?
But what if the window position is QPoint(0, 0)?
861 | - if ((!pos.x() && !pos.y()) || (QApplication::desktop()->screenNumber(parent) == -1)) 862 | - { 863 | - QRect screen = QApplication::desktop()->screenGeometry(); 864 | + 865 | + int screen_number = QApplication::desktop()->screenNumber(parent); 866 | + QRect screen = QApplication::desktop()->availableGeometry(screen_number);
What if the result of availableGeometry() when screen_number = -1?
Do you mean -1? If the parameter is -1, it returns the default screen
Fixed above comment.
utACK
857 | @@ -858,9 +858,9 @@ void restoreWindowGeometry(const QString& strSetting, const QSize& defaultSize, 858 | parent->resize(size); 859 | parent->move(pos); 860 | 861 | - if ((!pos.x() && !pos.y()) || (QApplication::desktop()->screenNumber(parent) == -1)) 862 | - { 863 | - QRect screen = QApplication::desktop()->screenGeometry(); 864 | + int screen_number = QApplication::desktop()->screenNumber(parent); 865 | + QRect screen = QApplication::desktop()->availableGeometry(screen_number); 866 | + if ((!pos.x() && !pos.y()) || screen_number == -1 || !screen.contains(parent->frameGeometry())) {
Does this allow a window that is halfway moved out of the screen (I think we should allow this)?
No I don't think it does, but I thought about that and the expected behaviour of most software is that it launches within the screen even if you moved it partially out last time?
utACK
I believe this was fixed here : #10156
I was about to remark this - there have been a few PRs before in the last few years 'fixing' this issue, but it keeps returning (or wasn't fixed properly after all). So normally we would make sure of this by unit tests but I don't think that's an option here due to the GUI-ness. So I suggest creating a manual testplan before/after, so we can verify that this bug is squashed.
Just tested on macOS and windows 8.1 (VM): Current master OSX: if I move the window outside of the boundary, it will relocate the window to the maximum boundaries without overlapping the visible area. With this PR OX: overlapping the boundaries will always lead to reopen it in the screen center. (I think this is acceptable, but slightly different to the current state).
Could not reproduce the issue on Windows 8.1 (did run on a very large screen, closes Bitcoin-Qt while having the main window on the right bottom, reduce screen by times 4, re-started Qt and had the window visible)
So it's unclear whether this is actually needed. Removing the milestone.