Qt Window positioning

JacobNovitsky

I'm trying to set Window to specific coords, leftmost on the screen
but still failing
Please advise how to fix below

#include <QApplication>
#include <QWidget>
#include <QLabel>
#include <QVBoxLayout>
#include <QScreen>

class TestWindow : public QWidget {
public:
    TestWindow(QWidget* parent = nullptr) : QWidget(parent) {
        QVBoxLayout* layout = new QVBoxLayout(this);
        QLabel* label = new QLabel("Test Position\nRight-most area", this);
        label->setAlignment(Qt::AlignCenter);
        layout->addWidget(label);

        setWindowTitle("Position Test");

        setStyleSheet("background-color: #ff6b6b; color: white; font-size: 16px;");
    }

    void moveToRightMost() {
        // Get the screen
        QScreen* screen = QGuiApplication::primaryScreen();
        if (screen) {
            QRect screenGeometry = screen->availableGeometry();

            int screenRight = screenGeometry.right();
            int screenTop = screenGeometry.top();

            int windowWidth = this->frameGeometry().width();  // include window frame
            int windowHeight = this->frameGeometry().height();

            int x = screenRight - windowWidth + 1;  // Align window's right edge
            int y = screenTop;

            move(x, y);
        }
    }
};

int main(int argc, char* argv[]) {
    QApplication app(argc, argv);

    TestWindow window;
    window.resize(479, 819);  // Set size before showing

    window.show();
    QApplication::processEvents();  // Let Qt calculate window frame size

    window.moveToRightMost();  // Move after shown and processed

    return app.exec();
}

Kent-Dorfman

so what is it doing when you run it? Does it move the window at all? Be advised that window positions are normally hints that can be overridden byt the window manager.

and since your movement logic sepends on "screen", wouldn't it be a good idea to verify that it is actually created by debug output if it fails "assert(screen)"?

Pl45m4

@JacobNovitsky

Are you using Linux with Wayland?

JKSH

@Pl45m4 said in Qt Window positioning:

Are you using Linux with Wayland?

This is an important question, because the Wayland protocol does not allow client windows to set their own positions.

SamiV123

@JKSH said in Qt Window positioning:

@Pl45m4 said in Qt Window positioning:

Are you using Linux with Wayland?

This is an important question, because the Wayland protocol does not allow client windows to set their own positions.

And X11 and Qt is so buggy that nothing works by default without doing a million timer hacks. I don't entirely blame Qt here, X11 with its async protocol is sketchy and causes a lot of headache.

Axel Spoerl

@SamiV123

And X11 and Qt is so buggy that nothing works by default without doing a million timer hacks. I don't entirely blame Qt here, X11 with its async protocol is sketchy and causes a lot of headache.

X11 and Qt have been working well for decades. If you have an issue, report it.
No general negative statements, please.

SamiV123

It's not negative, it's just what it is.

Try doing something like open a window and set focus to a specific window and find out that it won't work unless you add a timer hack. Or try to "activateWindow" after you created, oops doesn't work needs another QTimer workaround. I could go on, but I'm sure you get the point.

Of course saying that "nothing works" is hyperbole. The meaning being that stuff like "create a window, move it to a certain location" has a lot of caveats and often requires workarounds, and a lot of this stuff is due to the X11 async protocol brain damage that if the window is not "mapped" for example then your "request" to move the window won't work and the only way to workaround is to add a random time delay between the two.

Axel Spoerl

It's not negative, it's just what it is.

That you experience issues in specific use cases, doesn't mean it always is like that. In this forum, please report specific issues. Don't generalise.

X11 async protocol brain damage

Such expressions aren't welcome here. Please don't use them.

The timer use case looks like something you can solve by some design adjustment.
QWindow::show() will reliably show the window, just like QWidget::setFocus() or QWindow::requestActivate() will reliably transfer focus. These contracts don't mean that the desired outcome happens when the methods return. Events need to be processed for it to happen. If you call your dog, you need to give it some time to report to you.
There is absolutely no need for a timer. Just return to the event loop and listen to a signal, such as QWindow::focusObjectChanged() or QWindow::visibilityChanged(). These signals are emitted, when the initiated action has been completed.

This is also recommended on non-X11 platforms. X11's async implementation calls louder for signal-based implementations. However, Qt also requires event processing e.g. when focus is transferred from one window to another.

Again, if you have a specific issue, feel free to start a topic and the community will help you.
Just be nice and friendly :-)

SamiV123

"The timer use case looks like something you can solve by some design adjustment.
QWindow::show() will reliably show the window, just like QWidget::setFocus() or QWindow::requestActivate() will reliably transfer focus. These contracts don't mean that the desired outcome happens when the methods return. "

I'm sorry but to me this is self contradicting. They'll happen reliably, if when some event processing happens, maybe then. How's that reliable?

Anyway, if I had some more time I'd make a demo case of some problems that are really problematic such as embedding QWindow in a windowContainer. In my experience something like requestActivate has been very unreliable. But yeah, maybe it works for other people and I'm just "holding it wrong".

Regarding the issues, I'm on Qt5 so I already know the answer "report it against Qt6 or there's no issue".

Ps. Here's an issue I'm having just recently.
https://forum.qt.io/topic/163119/qt5-qwindow-inside-windowcontainer-not-receiving-keyboard-events-on-wayland?_=1757774913194

Axel Spoerl

@SamiV123 said in Qt Window positioning:

They'll happen reliably, if when some event processing happens, maybe then. How's that reliable?

If you just add some "if", "when" and "maybe" to any firm statement, you can claim that it's contradicting.

If you call requestActivate() on a window in X11, it will be activated. We have hundreds of autotests running every day to confirm that.

Of course it won't happen, if the event loop is blocked. Or if the user clicks somewhere else to focus another window. Or if a system popup steals focus.

Regarding the issues, I'm on Qt5 so I already know the answer "report it against Qt6 or there's no issue".

So basically you don't want to provide a reproducer, you prefer to stick with an outdated version of Qt, and now you blame X11 or Wayland to cause your problem?
Sounds like calling the road bumpy, while driving with a flat tire.

SamiV123

Outdated version?

Did it break?

This is definitely not within the scope of the original post but it really irks me that we (as in the people in software industry) force useless churn and busy work on each other.

Software is one of the things that is completely free of any constraints of the physical world. It doesn't rot, rust, decay or wear out. Yet it's completely broken and outdated all the time because people CHOOSE TO BREAK THINGS.

What does upgrading to Qt6 give me?

Let's see, I'll spend a 1 week fighting with the usual non-sense that involves upgrading to qt6 that breaks cmake, which requires cmake upgrade which breaks all the cmake files, which breaks all 3rd party libs cmakes which requires upgrading third party libs which all break because of transitive dependencies and libpng 1.2.3 does not work with libz 12.3 and with Qt6 or harfbuzz or freetype or whatever other libs that there are get sideways and cause massive issues etc.

Then when it finally configures it won't compile. When it compiles it won't link. When it links it won't run. When it runs it won't work.

After fighting through all this nonsense crap, has the VALUE of my software increased? Does it do more? Does have it more features, less bugs?

No, the best case scenario is that it does the same thing it did before. In reality it will probably have a bunch of new bugs. All this and I lose a week of working time that could actually be used used to create VALUE, fix bugs and add more new interesting features instead of running in a circle.

If I did every single update whenever GCC, MSVS, Emscripten, CMake, Python, Conan, Harbuzz, Freetype, etc etc updates I'd spend 100% of my time doing nothing but maintaining the build and nothing else. UJseless.

"and now you blame X11 or Wayland to cause your problem?"

Well.. if it's broken.. then it's broken... ¯_(ツ)_/¯

Axel Spoerl

Saying that software is free of physical world constraints has almost made my day. What was it again that you need to write, compile, run and actually use software? The latin verb "applicare" means to bring two elements in physical contact with each other. Its link to the physical world, with all its constraints, makes software applicable, useable, useful, successful.

Some of the main reasons for developing Qt6 were actually physical. OpenGL was state of the art, when Qt5 was started. Now we have RHI, Vulkan, Metal, Direct3D. The Qt6 graphics stack is much more advanced. Graphics cards have seen physical evolution, and Qt has followed. You are warmly welcome to ask your question in the Qt6 category of this forum.

But before you write again:
Your wrong, general negative statements about Wayland and X11 being broken, Qt 6 not configuring, compiling, linking, running, working, as well as bad language like "useless crap" - none of it is appreciated or welcome here. Please be advised to stop it now. You'll be banned if you do it again.

SamiV123

The software that was written 20 years ago can and could work just as well today as it did it when was written. It does not rot on its own. If it does not the reason is man made.

I'm not against evolution, I'm against forcing breakage on people, breaking APIs compatibility, libraries, tools version after version after version. There's no value there. Somehow maintaining things is also possible..just look at Win32 API that is stable and one can take an app written 20 years ago and still run it today.

I didn't mean that qt6 would not build. I mean that in a large software project that relies on multiple tools and 3rd party libraries any change anywhere WILL break the project build.

SimonSchroeder

@SamiV123 said in Qt Window positioning:

Somehow maintaining things is also possible..just look at Win32 API that is stable and one can take an app written 20 years ago and still run it today.

I am not sure if fixing a bug, then noticing it breaks certain software and because of that writing a work around to keep the bug when that software is running is a good strategy. You don't get the best API when it's totally bloated. It takes more time to maintain a larger API which means less new features (and fewer bug fixes).

Also, I choose C++ as programming language because I need good performance. This also requires good performance of the libraries I'm using. Qt is one of those libraries. I would claim that bloated libraries (with work arounds like in Windows) steal some of your performance (work arounds are not free if you don't need them).

Honestly, we are also still using Qt 5. (But we also have one student using Qt 6. It is not too much work to port.) We are a small company which mostly survives not from software sales. We don't have the money (and time) to constantly switch versions. I am not sure I need 20 year-old software running perfectly fine today (probably it wouldn't because we didn't have 4k high-resolution displays back then). However, it would be nice to only have to switch every 10 or 12 years or so. Large software companies might be able to switch every 3 years, but small companies (and hobby projects and small open source projects) might need much longer stretches.

So, I agree that we need longer maintenance periods, but I'm not sure if the Windows model is the right one. (Apple's maintenance model is too short for me. They are already fading out Rosetta 2 and my 2015 MacBook Pro has also not been supported for several OS versions for no specific reason.)

PS: Windows also occasionally drops support. At some time they have dropped support for 16-bit applications (but that has been probably more than 20 years). I also remember that I couldn't install some software (which would have still run perfectly otherwise) because my hard drive was too large. (Remember back in the day when installers would compute install size and would let you install if there wasn't enough space? Once your hard drive gets larger than they expected you get negative hard drive sizes reported.)