Robust interception of ApplicationWindow geometry initialisation

Bob64

I am trying to address an issue that has been reported whereby my application can start up with the main window outside the bounds of the current screen area.

Main window geometry (and a few other things) are persisted using Settings.

Typically the issue happens with users on laptops docking with different screen setups, perhaps moving between work and home.

What I want to do is detect whether the main window starts up with a geometry so far out of screen bounds that the user has no access to the title bar. If so, then adjust the window geometry to make it visible.

The part of this I am unsure about is detecting the initial geometry so that I can apply the test. As far as I can see there is no about to show event or similar where it is guaranteed that any initial settings have been made.

What I have done so far is something like this:

ApplicationWindow {
    id: appWindow

    Connections {
        target: appWindow
        function onXChanged() { ... }
        function onYChanged() { ... }
        // ditto for height & width
    }

Each on<...>Changed handler starts a timer that introduces a small delay before we try to do anything. The assumption is that by the time the timer is triggered, all relevant settings have been applied. When the timer is triggered, we check the current appWindow geometry against the available screen geometries and adjust x, y, width, height if necessary.

I also have a boolean flag to ensure that this all happens only once and not every time that the window is subsequently moved or resized.

While this seems to work, it all feels a bit ad hoc and hacky. I wondered if I might be missing a more robust or a cleaner approach.

Bob64

Just to add some further explanation, I was unsure whether Settings would be applied before Component.onCompleted is triggered. Furthermore, I avoided trying to do this in Component.onCompleted because of the documentation in Screen:

Note that the Screen type is not valid at Component.onCompleted, because the Item or Window has not been displayed on a screen by this time.

However, I have just realised that Screen is documented as being an attached property of a Window or Item so this caveat does not necessarily apply to the screen property of Window or to Qt.application.screens.

If I can reliably do what I want to do in Component.onCompleted, I think it is much simpler.

Bob64

OK, so this certainly seems to work and is much cleaner if I do the work in Component.onCompleted. What I am missing is a guarantee that the Settings have been applied to the window geometry by the time Component.onCompleted is triggered.