QMessageBox position and size are wrong
-
I had this application on hold for a long time and when came back - on new OS install with latest QT 6 - I encountered a problem with QMessageBox...
void AppWindow::closeEvent(QCloseEvent *event) { if(QMessageBox::question(this, "Exit", "Are you sure?", QMessageBox::Yes | QMessageBox::No) == QMessageBox::Yes) { computer.requestInterruption(); computer.wait(); event->accept(); } else { event->ignore(); } }
I was expecting - and remember that it was so - the message box to be centred on its parent and be correctly sized... But I got this...
As you can see the message box not centred and the size is incorrect, as the title not even shows...
This is my environment:
OS: Fedora 39
QT: 6.6.2
QT Creator: 10.0.2
Compiler: gcc 13.3.1While everything functioning perfectly I would like it to be also pleasing to the eye...
-
Do you use wayland?
-
Do you use wayland?
And I mean by that, that Fedora 39 using wayland...
-
@JonB
I do not understand what are you suggesting... I do not control not size neither position. I left it to the default, which - to my understanding - should be centred...
And if I have to write special code to deal with the underlying wayland layer, then what the point in QT? -
I am not suggesting anything.
I was expecting - and remember that it was so - the message box to be centred on its parent and be correctly sized... But I got this...
I asked whether you are running under Wayland. If so, Wayland will position the message box for you, and that may override the centering of a message box which perhaps used to happen under, say, Xorg, if that is what you used in the past.
And if I have to write special code to deal with the underlying wayland layer, then what the point in QT?
You don't have to write special code if it is a Wayland issue, and indeed it would be difficult to do so. Rather you accept that Wayland positions windows according to its rules. (Part of) The point of Qt is to provide a platform-independent layer for code including windowing functionality, not to somehow override or by-pass the native windowing system/manager.
The first thing is to ascenrtain if you are running under Wayland. If you are not this is not relevant. If you are then try your code under Xorg and see if different behaviour?
-
I am not suggesting anything.
I was expecting - and remember that it was so - the message box to be centred on its parent and be correctly sized... But I got this...
I asked whether you are running under Wayland. If so, Wayland will position the message box for you, and that may override the centering of a message box which perhaps used to happen under, say, Xorg, if that is what you used in the past.
And if I have to write special code to deal with the underlying wayland layer, then what the point in QT?
You don't have to write special code if it is a Wayland issue, and indeed it would be difficult to do so. Rather you accept that Wayland positions windows according to its rules. (Part of) The point of Qt is to provide a platform-independent layer for code including windowing functionality, not to somehow override or by-pass the native windowing system/manager.
The first thing is to ascenrtain if you are running under Wayland. If you are not this is not relevant. If you are then try your code under Xorg and see if different behaviour?
Thank you for the explanation - now I see what you was saying...
I was under the impression - based on what I saw in the documentation - that the modal shuld be automatically centred by QT, regardless of the underlying technology...
Displays a simple message box about Qt, with the given title and centered over parent (if parent is not nullptr).
Not aboutQt neither question does it...I will try what called 'property-based API' in the documentation to solve the problem...
Thank you
-
Thank you for the explanation - now I see what you was saying...
I was under the impression - based on what I saw in the documentation - that the modal shuld be automatically centred by QT, regardless of the underlying technology...
Displays a simple message box about Qt, with the given title and centered over parent (if parent is not nullptr).
Not aboutQt neither question does it...I will try what called 'property-based API' in the documentation to solve the problem...
Thank you
@kepeter
I agree about that doc quote, but I am not sure whether it does not apply under Wayland. You still have not stated whether you are running under Wayland. If you are, and that is the reason, there is nothing for you to do about it. I don't know about a "property-based API'". Leave it to you to find out if you are under Wayland and this is a Wayland behaviour. -
@kepeter
I agree about that doc quote, but I am not sure whether it does not apply under Wayland. You still have not stated whether you are running under Wayland. If you are, and that is the reason, there is nothing for you to do about it. I don't know about a "property-based API'". Leave it to you to find out if you are under Wayland and this is a Wayland behaviour.I missed your question about wayland (answered it earlier) - Fedora 39 uses wayland so I'm using it...
I fiddled with the message box and found this:
msg1 will center on the parent window, but will not show title bar
QMessageBox msg1; msg1.setParent(this); msg1.setText("Are you sure?"); msg1.setWindowTitle("Exit"); msg1.setStandardButtons(QMessageBox::Yes | QMessageBox::No); msg1.setDefaultButton(QMessageBox::No); msg1.setIcon(QMessageBox::Question); msg1.setWindowFlags(Qt::Popup); msg1.exec();
msg2 will show title bar, but will not center
QMessageBox msg2; msg2.setParent(this); msg2.setText("Are you sure?"); msg2.setWindowTitle("Exit"); msg2.setStandardButtons(QMessageBox::Yes | QMessageBox::No); msg2.setDefaultButton(QMessageBox::No); msg2.setIcon(QMessageBox::Question); msg2.setWindowFlags(Qt::Dialog); msg2.exec();
It seems some sort of bug - not sure where exactly, however I can be with the first option... So I will call it a day...
Thank you...
-
I had this application on hold for a long time and when came back - on new OS install with latest QT 6 - I encountered a problem with QMessageBox...
void AppWindow::closeEvent(QCloseEvent *event) { if(QMessageBox::question(this, "Exit", "Are you sure?", QMessageBox::Yes | QMessageBox::No) == QMessageBox::Yes) { computer.requestInterruption(); computer.wait(); event->accept(); } else { event->ignore(); } }
I was expecting - and remember that it was so - the message box to be centred on its parent and be correctly sized... But I got this...
As you can see the message box not centred and the size is incorrect, as the title not even shows...
This is my environment:
OS: Fedora 39
QT: 6.6.2
QT Creator: 10.0.2
Compiler: gcc 13.3.1While everything functioning perfectly I would like it to be also pleasing to the eye...
-
@anil_arise Wayland does not allow moving top level widgets. Otherwise the OP would not have such problems...
-
@anil_arise Wayland does not allow moving top level widgets. Otherwise the OP would not have such problems...
@Christian-Ehrlicher
These are NOT top-level... Every and each has a parent... -
@Christian-Ehrlicher
These are NOT top-level... Every and each has a parent...@kepeter said in QMessageBox position and size are wrong:
These are NOT top-level... Every and each has a parent...
It is top-level. Read https://doc.qt.io/qt-6/qdialog.html#QDialog
Constructs a dialog with parent parent.
A dialog is always a top-level widget, but if it has a parent, its default location is centered on top of the parent
Dialogs only use parent for positioning. And we believe Wayland ignores/does not allow that.
-
@kepeter said in QMessageBox position and size are wrong:
These are NOT top-level... Every and each has a parent...
It is top-level. Read https://doc.qt.io/qt-6/qdialog.html#QDialog
Constructs a dialog with parent parent.
A dialog is always a top-level widget, but if it has a parent, its default location is centered on top of the parent
Dialogs only use parent for positioning. And we believe Wayland ignores/does not allow that.
-
It's not a child dialog but a top level widget. Child dialogs are properly centered as you can see in the testcase above.