Windows placement review (project manager, editor run, exported game)

[akien-mga]

Over the years we have had various issues about the placement of Godot's windows, sometimes contradictory and with partial platform-specific or configuration-bound fixes. All in all it's pretty hard to have a good overview of what is happening today, so starting this issue to gather the information. I will close all other issues on this topic and point to this one.

Godot spawns different kind of windows, with different behaviours for each window and each platform:

• Project manager
• Editor window
• Running game in editor (placement can be configured in Editor Settings, should default to Centered)
• Running game outside of editor, with editor binary (run Godot in the project folder)
• Exported game

I want to know what is the behaviour on all desktop platforms for those 5 kinds of windows:

• Where does the window spawn?
• Does it "jump" from one location to another (e.g. start appearing top left and then jump in the center before rendering)?
• Anything else that seems relevant

And having the status for both the master branch and the 2.1 branch would be nice.

So you get the test matrix, 3 platforms, 5 types of windows, 2 behaviours to describe, 2 branches.

[akien-mga]

OS: Mageia 6 x86_64 (Linux) X11 1.6.5, KDE Plasma 5.8.7, kernel 4.9.34, nvidia 376.66

Godot version: master, 3509acd

• Project manager: Bottom left corner, without conflicting with taskbar. The location actually depends on the other windows I have opened in KDE Plasma, if I already have an instance of the project manager in the bottom left, a second instance would spawn in the bottom right. After closing the editor and going back to the PM, it spawns in the top left...

• Editor window: Fullscreen, splash screen in top left and glitches while loading

• Running game in editor (default config == centered): Starts spawning in the top left as a transparent window, then the proper window renders in the center.

• Running game outside of editor: Same behaviour as the project manager window

• Exported game: not tested

[akien-mga]

OS: Mageia 6 x86_64 (Linux) X11 1.6.5, KDE Plasma 5.8.7, kernel 4.9.34, nvidia 376.66

Godot version: 2.1, 9d49491

Exact same behaviour at for master described above. (Exported game also not tested)

[Zylann]

A user had a problem with the window opening under its taskbar, making it annoying to move it. It's a special case where the window is actually too big to fit, however the titlebar should always be pickable, if possible, because it would make UX better: https://godotengine.org/qa/16012/how-to-fix-top-of-screen-clipping-in-windows

[akien-mga]

A user had a problem with the window opening under its taskbar, making it annoying to move it. It's a special case where the window is actually too big to fit, however the titlebar should always be pickable, if possible, because it would make UX better: https://godotengine.org/qa/16012/how-to-fix-top-of-screen-clipping-in-windows

That's a different issue and a corner case, I'd prefer we keep this issue focused on the behaviour on a plain default-sized window. So this issue should likely have its own bug report, and be investigated once we're happy with the default placement in non-oversized scenarios.

[eon-s]

Ubuntu 17.04, Gnome 3.22:

Godot 2.1.x:

• Project manager: Top left.
• Editor window: Show a splash screen top left, quickly maximized, top left (cascade sorted) if reverted to regular size.
• Game window: Centered.
• Running game outside editor: Top left (cascade sorted).

Godot 3:

• The same except for (in-editor) game window forced on top left (over editor window if got the chance to be there).

By default, Gnome in Ubuntu seems to create subsequent windows on cascade fashion, regular size editor window is more than a title bar below the project manager if the later was on the top left.

[reduz]

i suppose the project manager should be centered...

On Tue, Jun 27, 2017 at 7:37 PM, eon-s notifications@github.com wrote:

Ubuntu 17.04, Gnome 3.22:

Godot 2.1.x:

• Project manager: Top left.
• Editor window: Show a splash screen top left, quickly maximized, top left (cascade sorted) if reverted to regular size.
• Game window: Centered.
• Running game outside editor: Top left (cascade sorted).

Godot 3:

• The same except for (in-editor) game window forced on top left (over editor window if got the chance to be there).

By default, Gnome in Ubuntu seems to create subsequent windows on cascade fashion, regular size editor window is more than a title bar below the project manager if the later was on the top left.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/9418#issuecomment-311505779, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z29BTAFPLzcVGxk9wk04kEzjL-5Lvks5sIYQagaJpZM4OG_8D .

[melix99]

macOS Sierra 10.12.5:

Godot 3 master (6fd4311c27625a5c725fcf525bbbf04fbbf9c56f):

• Project manager: Centered, almost? (The height doesn't seems to be perfectly centered).

• Editor window: Maximized, without splash screen (It just pops out the editor)

• Running game in editor with window config to "Default" (It was the default option for me): Bottom left.

• Same with config to "Centered": Perfectly centered (unlike the project manager, that's strange).

• Running game outside of editor: Same as running game in editor.

Godot 2.1 branch (e3f9653353c0f5c8f3783acaf1bf5f47c4cb1050): identical to Godot 3

[ghost]

Not sure if this is the right place for this, so apologies if I'm mistaken.

The default unmaximized window size is, in my opinion, impractically small. Panel widths will be shrunk down to accomodate for the small size, which can be a little annoying; but what's even worse is if the panels can't be shrunk down enough (eg. having a dock in every column), they just get pushed out of the window:

This problem is exacerbated by the fact that there's no way to save the window size, or even change the default. I think it's just hard-coded to re-use the project manager's window size:

I think the default window size could be a little larger; something like 1280x720 should be fine for everyone these days. Ideally there would also be a way to save the window size per-project, or at least have it persist between sessions.

Tested on ab13d0a, Linux Mint 18.2 Cinnamon x64

[Zireael07]

What's your resolution @homer666 ?

[ghost]

@Zireael07 I have two monitors; the main one is 2560x1440 and the secondary one is 1280x1024, which isn't shown in the screenshots. Why do you ask?

[Zylann]

It looks like Godot took the wrong monitor resolution

[ghost]

No, I don't think this is dependent on my monitor resolutions at all. Just to clarify, the editor starts off maximized as expected, but when I unmaximize it, the resulting window is the exact same size as the initial Project Manager window. I have tested this on both my desktop computer (with and without the secondary monitor, on both Linux Mint and Windows 10) and and on my 1366x768 laptop, and I'm able to replicate this consistently. Try it yourself.

[AlexHolly]

Can we add a second setting for the window placement(Editor Window, Game Window)? I want to spawn the game always on screen2 and the Editor on screen1.

Every time I start the editor I have to drag from screen2 to screen1.

[rraallvv]

@Melix19

I'm addressing the issue for macOS here for version 2.1 and here for the master branch, and would love feedback.

@reduz

Maybe we could use some kind of specification for all platforms, and use a set of test to warrant that these specifications are met. I was suggested that editor_run.cpp wasn't modified and that the issue should be addressed from os_osx.mm. I explain here how I used a few helper functions to convert native coordinates to the ones expected by Godot.

A few assumptions that I made from the way editor_run.cpp works:

# 1) set_windows_position(), get_window_position(),
# and OS.get_screen_position() all use absolute values

# 2) window doesn't move if setting its position to its current position
OS.set_windows_position(OS.get_window_position())

# 3) setting the window position to the current screen position
# moves the window to the top left corner of the current screen
OS.set_windows_position(OS.get_screen_position(OS.get_current_screen())) 

# 4) setting the position to (0, 0) moves the window to the 
# top-left position of the smallest rectangle that encompasses
# all the screens (it could be outside of the visible area)
OS.set_windows_position(Point2(0, 0)) 

For the last one (4) the specification might require instead that the origin from where all coordinates are relative is in some other place, for instance at the top-left coordinate on the screen with index 0.

Without an specification it will be difficult to solve the issue so that positioning the window behaves consistent in all platforms.

[fleskesvor]

I tried to run GDquest's presentation on my work Mac, a 2016 MacBook Pro recently upgraded to High Sierra, but I'm having some problems with positioning. Both when running in windowed mode and borderless fullscreen, the viewport is skewed far down and to the right, as can be seen in the screenshots. On Linux, on the other hand, the presentation runs in proper fullscreen and is centred on the screen as expected. I'm assuming there's no problems on Windows either, since GDquest is a Windows user, if I remember correctly.

I have also tried running the Escoria demo (and Escoria in Daïza), and it exhibits the same issue.

EDIT: The editor itself is positioned perfectly though.

[rraallvv]

@fleskesvor I'll give it a try, is this (https://github.com/GDquest/godot-3-presentation) the presentation?

Edit: Could you please post a screenshot on Linux with how it's supposed to look like? Thanks.

[fleskesvor]

@rraallvv Thanks for looking into it. Yes, that's the one.

On Linux, it looks like this in windowed mode and this fullscreen.

It's actually a little too big to run in windowed mode as it is on my Linux laptop with a 1366x768 resolution. The Mac has a 2880x1800 retina display.

[rraallvv]

@fleskesvor

Have you tried with the option Resizable turned on in the project settings? Display/Window/Size/Resizable

Then controlling the window placement in the editor settings in Run/Window Placement/Rect

I don't have a retina display and couldn't reproduce the issue with a fake resolution using RDM

Also, it'd help if you could please post the console output in the terminal window after you run the presentation?

Running Godot like so if you are in the path to where you cloned Godot:

$ bin/godot.osx.tools.64 --editor --path path/to/godot-3-presentation

This should show something like this:

Running: /Users/user/Desktop/godot/bin/godot.osx.tools.64 --path /Users/user/Downloads/godot-3-presentation-master/godot-3-presentation --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 8549 --position 320,180 arguments 0: /Users/user/Desktop/godot/bin/godot.osx.tools.64 1: --path 2: /Users/user/Downloads/godot-3-presentation-master/godot-3-presentation 3: --remote-debug 4: 127.0.0.1:6007 5: --allow_focus_steal_pid 6: 8549 7: --position 8: 320,180 Current path: /Users/user/Downloads/godot-3-presentation-master/godot-3-presentation Remote Debugger: Connection failed with status: '2', retrying in 1 sec. OpenGL ES 3.0 Renderer: Intel HD Graphics 4000 OpenGL Engine GLES3: max ubo light: 409 GLES3: max ubo reflections: 455, ubo size: 144 ARVR: Registered interface: Native mobile ERROR: set_current_animation: Condition ' !animation_set.has(p_anim) ' is true. At: scene/animation/animation_player.cpp:998. tf varying: 0 out_color tf varying: 1 out_velocity_active tf varying: 2 out_custom tf varying: 3 out_xform_1 tf varying: 4 out_xform_2 tf varying: 5 out_xform_3

Maybe you could try to patch platform/osx/os_osx.mm to show the display scale in the console output too:

void OS_OSX::set_native_window_position(const Point2 &p_position) {

    NSPoint pos;
    float displayScale = _display_scale();

    printf("Display scale: %f\n", displayScale); // <-- add this line

    pos.x = p_position.x / displayScale;
    pos.y = p_position.y / displayScale;

    [window_object setFrameTopLeftPoint:pos];

    _update_window();
};

[fleskesvor]

@rraallvv I should have mentioned that this problem occurred with the pre-compiled beta release from https://downloads.tuxfamily.org/godotengine/3.0/beta1/ I have no such issues when compiling from source. Sorry for creating unnecessary work for you. 😞

[rraallvv]

@fleskesvor it was not a problem at all. I'm glad I could be of help.

[mhilbrunner]

@AlexHolly You should open a seperate issue to request that as a feature.

[akien-mga]

I think things are more or less working as expected now for 3.0. If not, from now on it might be easier to track issues for each platform in their own tickets.