QWidget::pos() using Ubuntu on WSL
-
The app I am developing using 6.5.0 runs fine on both Windows and Ubuntu using WSL2. However there is one thing wrong: on the WSL Ubuntu the QWidget pos() always returns the same bogus QPoint(-3,-30) value. Similarly move() does not work right either.
Should I even expect this to work on linux running on windows? Or is there something I am doing wrong? It seems linux builds use this inbuilt Wayland display manager. So is this a Qt bug or an error on my part?
-
The app I am developing using 6.5.0 runs fine on both Windows and Ubuntu using WSL2. However there is one thing wrong: on the WSL Ubuntu the QWidget pos() always returns the same bogus QPoint(-3,-30) value. Similarly move() does not work right either.
Should I even expect this to work on linux running on windows? Or is there something I am doing wrong? It seems linux builds use this inbuilt Wayland display manager. So is this a Qt bug or an error on my part?
@ChortleMortal What do you mean "does not work right?" How are you concluding that position is bogus? It's not clear what problem you are having.
-
The app I am developing using 6.5.0 runs fine on both Windows and Ubuntu using WSL2. However there is one thing wrong: on the WSL Ubuntu the QWidget pos() always returns the same bogus QPoint(-3,-30) value. Similarly move() does not work right either.
Should I even expect this to work on linux running on windows? Or is there something I am doing wrong? It seems linux builds use this inbuilt Wayland display manager. So is this a Qt bug or an error on my part?
@ChortleMortal :"does not work right" means it does not move to the correct position. I cant imagine what else it could mean. The move() function has only one purpose which is to move to a positioon and it does not do that. It appears to me that whatever QPoint that I supply it is ignored and the widget appears at some (seemingly) random position whether or not I make tehe call at all. pos() and move() are not working all.
I was hoping for some wisdom on this from the community, but I guess if there is no understanding, I could report this as a bug to Qt and they could determine if it is indeed a bug or not.
-
@ChortleMortal :"does not work right" means it does not move to the correct position. I cant imagine what else it could mean. The move() function has only one purpose which is to move to a positioon and it does not do that. It appears to me that whatever QPoint that I supply it is ignored and the widget appears at some (seemingly) random position whether or not I make tehe call at all. pos() and move() are not working all.
I was hoping for some wisdom on this from the community, but I guess if there is no understanding, I could report this as a bug to Qt and they could determine if it is indeed a bug or not.
@ChortleMortal QPoint(-3,-30) doesn't sound bogus at all. It's most likely the size of the window frame, so the position of your widget would be (0,0) and that's the negative offset for the frame.
As to why it's at (0,0) I couldn't tell, but I doubt it's a problem with Qt. All it really does is translates native messages, so it's more likely some quirk of WSL.Does it happen to other apps too, specifically non-Qt ones?
Can you move the window around by dragging it? If you can what's the reported pos() after the move?If you suspect it's Qt misbehaving you can implement nativeEvent handler and see what's coming directly from the OS when you move the window around. If the value is wrong there already there's not much Qt can do about it and it's a problem of WSL or your Linux distro.
-
@ChortleMortal QPoint(-3,-30) doesn't sound bogus at all. It's most likely the size of the window frame, so the position of your widget would be (0,0) and that's the negative offset for the frame.
As to why it's at (0,0) I couldn't tell, but I doubt it's a problem with Qt. All it really does is translates native messages, so it's more likely some quirk of WSL.Does it happen to other apps too, specifically non-Qt ones?
Can you move the window around by dragging it? If you can what's the reported pos() after the move?If you suspect it's Qt misbehaving you can implement nativeEvent handler and see what's coming directly from the OS when you move the window around. If the value is wrong there already there's not much Qt can do about it and it's a problem of WSL or your Linux distro.
@Chris-Kawa
Thanks for you posting Chris.You ask: "Can you move the window around by dragging it? If you can what's the reported pos() after the move?" Yes my app has two windows, they can both be moved around. They always give the same result to QWidget:pos(). Of course this same code works fine on windows, but not non WSL/Ubuntu. To be clear, the QWidget is the 'frame'. It has no parent, which implies the desktop is the parent. What I am doing is saving the position in QSettings on the destructor, and restoring the postion using move() and the constructor when the app is started again.
You ask: "Does it happen to other apps too, specifically non-Qt ones?" I have no answer to this. QWidget::pos() is a specific Qt function, as is QWidget::move().
Thanks for the link to the native event handler, I had not heard of this before. From the documentation, it only seems to work wit windows, macos, and linu/xcb - so I don't know what will happen with a windows/wsl/wayland combination. But I will give it a try. I'm traveling this week, so may not get a chance to look at it until next week.,
-
@ChortleMortal :"does not work right" means it does not move to the correct position. I cant imagine what else it could mean. The move() function has only one purpose which is to move to a positioon and it does not do that. It appears to me that whatever QPoint that I supply it is ignored and the widget appears at some (seemingly) random position whether or not I make tehe call at all. pos() and move() are not working all.
I was hoping for some wisdom on this from the community, but I guess if there is no understanding, I could report this as a bug to Qt and they could determine if it is indeed a bug or not.
@ChortleMortal said in QWidget::pos() using Ubuntu on WSL:
whatever QPoint that I supply it is ignored and the widget appears at some (seemingly) random position
So, you are saying you can move before the widget is shown? Have you tried moving the widget after it is shown? The window manager on Linux will tend to be responsible for initial window placement when shown. So if you set pos, then show, then WM moves it, it'll wind up where the WM moves it. If you show, WM does initial placement, then you move it, it'll appear where you want.
"does not work right" means it does not move to the correct position. I cant imagine what else it could mean. The move() function has only one purpose which is to move to a positioon and it does not do that. It appears to me that whatever QPoint that I supply it is ignored and the widget appears at some (seemingly) random position whether or not I make tehe call at all. pos() and move() are not working all.
I was hoping for some wisdom on this from the community, but I guess if there is no understanding,
Please don't be rude when I ask a followup question. Your initial post was extremely vague and didn't have enough information for a more useful response than a followup question. You said literally nothing that would indicate why you thought -3,-30 would be a bogus value. In many circumstances, it would be perfectly normal to have a window at that position.
-
@Chris-Kawa
Thanks for you posting Chris.You ask: "Can you move the window around by dragging it? If you can what's the reported pos() after the move?" Yes my app has two windows, they can both be moved around. They always give the same result to QWidget:pos(). Of course this same code works fine on windows, but not non WSL/Ubuntu. To be clear, the QWidget is the 'frame'. It has no parent, which implies the desktop is the parent. What I am doing is saving the position in QSettings on the destructor, and restoring the postion using move() and the constructor when the app is started again.
You ask: "Does it happen to other apps too, specifically non-Qt ones?" I have no answer to this. QWidget::pos() is a specific Qt function, as is QWidget::move().
Thanks for the link to the native event handler, I had not heard of this before. From the documentation, it only seems to work wit windows, macos, and linu/xcb - so I don't know what will happen with a windows/wsl/wayland combination. But I will give it a try. I'm traveling this week, so may not get a chance to look at it until next week.,
@ChortleMortal said:
What I am doing is saving the position in QSettings on the destructor, and restoring the postion using move() and the constructor
You should be doing that on closeEvent and first showEvent. Depending on given platform plugin implementation there might be no underlying native surface yet in the constructor.
-
@ChortleMortal said:
What I am doing is saving the position in QSettings on the destructor, and restoring the postion using move() and the constructor
You should be doing that on closeEvent and first showEvent. Depending on given platform plugin implementation there might be no underlying native surface yet in the constructor.
@Chris-Kawa
Curioser and Curioser. I took Chiri's advice and moved the code into closeEvent and first showEvent. Nothing changed. Except on further instpection I see the bogus position changes from -3,30 to -6,60, -9, 90 etc. I neglected to say I am running this from qtCreator, so I don't know if this affects things; it doesn't on windows.So I started to hook moveEvent, resizeEvent. and mouseMoveEvent. Interestingly resizeEvents and mouseMoveEvents work perfectly, but I am not getting moveEvents at all, even though I can move the windoews with a mouse.
So I am about at the end of the road on this. I'm saying to myself 'it just doesn't work right using WSL'. I'd be interested if anyone is doing this using WSL and says 'yes it works' or has repoduced this using an app with a single widget and sees if they get moveEvents or get reasoanable values from pos(). I may get an old real Linux box out of storage sometime and see if it works - but I would expect it does, it worked the last time I tried it, but that was back in the days of qt5 and I'm now running qt6.5.0.
Thanks for the advice,
David
