DisplayServer: Window set_position semantics change based on single window mode

[derammo]

Godot version

4.0 dev (4173a47)

System information

Windows 10

Issue description

Summary

The Window::set_position(...) call takes coordinates as an argument and moves a window (top level OR popup) to that location/

In single window mode it takes coordinates relative to the main window, presumably like 3.x.

In multi window mode it takes absolute screen coordinates, so things can end up on an entirely different monitor for example.

Impact

Any application code using this API that works as expected in single window mode won't do the right thing in multi window mode and vice versa, unless the code always checks the window mode.

Commentary

It might be better if 4.0 had a separate Window::set_screeen_position or something like that if the semantics are going to be that different. Or screen-space positioning could be done relative to a Display, so that you have to specify both.

This was only tested on Windows.

Steps to reproduce

This is an internal issue against the API. Reproducing it requires writing code to use that API and calling it and observing the results in both single- and multi window modes.

Minimal reproduction project

No response

[h0lley]

Confirming this for v4.0.alpha11.official [afdae67] and Ubuntu.

Reproduction:

You require at least two monitors to reproduce this.

1. Create a new project
2. Place the editor window on your right monitor
3. In editor settings, ensure that window placement is set to "same as editor"
4. Create a new scene with any type of root node
5. Launch test play and notice that the window is placed on your right monitor as expected - the same as the editor
6. Attach a script to the root node and put this this in _ready():

get_viewport().position = get_viewport().position

7. Run the game again and notice that the window ends up on your left monitor, when of course that code shouldn't have any effect

edit: reading this again this might be a different issue. what I am describing definitely seems to be a bug.

[Sauermann]

Window::set_position is always in the coordinate system of the Window's embedder. The embedder can be the Window Manager Screen.

The single-window-mode config-option can change, who the embedder of a Window is. But since this is a user-configurable option, the user should know, if it is switched on or not. So in most cases, this should not be a problem.

In the other cases, for convenience the three functions CanvasItem::get_screen_transform, CanvasItem::get_screen_position and CanvasItem::get_screen_rect can help with that.

    var c: Control = $Control
    var w: Window = $"Control/Window"
    w.position = c.get_screen_position()

This script will position the Window so that it is at the location of the Control, not matter, where the Window is embedded.
Internally these functions are used for positioning popups or tooltips.

[akien-mga]

Closing following above comment.