Details

It seems like blender always opens windows like preferences in the top left corner of the screen. And then I immediately have to move it manually to the center of the screen before I start using it due to OCD.

New features:

by default, windows open in the center of the main display.

window positions and state (maximized/minimized) are saved when they are closed.

when opening a window, previous position and state is used.

if there is no previous position or state information, defaults are used.

windows are constrained to opening within a physical display. otherwise, defaults are used. (command line positions currently override this)

for "temp" windows, one of each type can be open at once (render, preferences) - not sure if this will break anything

Overview of code changes:

added GHOST_GetDisplayDimensions() to support multiple displays.

updated getWindowBounds() and createWindow() methods so that when the dimensions returned by getWindowBounds() are used in subsequent createWindow() calls, it creates a window in the same size and position.

removed x, y parameters from WM_window_open_temp(). the user preferred position (the last position a window was closed in) is now used, or the window is positioned centrally in its parent.

added 'type' to wmWindow and a WM_WINDOW_DEFAULT type, previously these types were only used for "temp" windows.

it seems like this is an invalid assumption - I just realised maximised windows have a smaller title bar in windows. bit of a chicken and egg problem with this code, as you need to have created the window before you can get the title bar size from ghost window.

How is this supposed to work on multi-display Linux? I'm doing blender --factory-startup and the window is opened in a way which makes it to stick to the right edge of my left monitor (the window is vertically aligned on center though).

How is this supposed to work on multi-display Linux? I'm doing blender --factory-startup and the window is opened in a way which makes it to stick to the right edge of my left monitor (the window is vertically aligned on center though).

Didn't test other platforms yet.

I've only tested it on ubuntu running on vmware on windows. I will try to set up my computer to run linux natively and look into this

However I have doubts about the way window position and size are saved. Currently window layout is saved in the startup file and .blend files. There you can put Windows in specific places with specific contents, and Blender will restore it. If we store the window size and position separately this will get out of sync, it's not obvious that the positions and size for one specific window setup should apply to another.

I would rather keep this state in .blend files. I guess a problem is that we do not save position and size for temporarily windows like render or preferences. However there is a more general problem here. Users also want the preferences to remember the scrolling state or the file browser to remember certain states. So maybe that can be solved somehow without windows.txt?

It would be good to split this into two patches. One for the defaults and another for saving the state.

@Brecht Van Lommel (brecht) the idea here is to have blender remember the state of the windows on close, not on save.
So I think the easiest way would be to store this info in a separate file (as it is currently in this patch).

Otherwise we would have to save changes to .blend files when the users close the application.

I think the problem here is that many do not know that the .blend files stores this information.
As can be seen by the requests to have blender start maximized. If it was intuitive, people would just realize that they could save the startup file in a maximized state and be done with it.

I just tried master on my mac and that doesn't seem to be the case for blender - neither the main window or preferences window remembered where I put them.

I'm not sure about saving inside the blend file - this really depends on the display of the system used, how many displays you have and the size really dictate how the windows should be restored.

I agree, that's why I separated it from the blend file. If I open someone else's blend file, I don't want the preferences window to open where they last closed it, I want it to appear where I put it and the size that I had it last.

How is this supposed to work on multi-display Linux? I'm doing blender --factory-startup and the window is opened in a way which makes it to stick to the right edge of my left monitor (the window is vertically aligned on center though).

I can't reproduce this problem yet. For me it starts maximised on the main display with --factory-startup. I'm using ubuntu 18.04.2 with gnome 3.28.2. What are you using?

This seems like a heavy solution for a problem that's not that bad, on OSX apparently this isn't needed?
Window managers on Linux can save window locations too (don't know about win32?)

It's adding a lot of code for something we have mostly been able to ignore.
Further, since Blender isn't an application that makes heavy use of many floating windows, it's not such a benefit - given the trade-off of code maintenance/complexity.

OTOH having access to multiple monitors display size seems generally useful and could be split into it's own patch.

Think we could attempt something less involved then this patch proposes, eg:

Store the monitor used for opening a temporary window, so toggling the a window uses that monitor again.

Think we could try remove this, the data is cache for ghost - if its need we can have an API call to access it.

It means the window size is stored in 3 places (4 if you count wmWindowPositions) so ensuring they're valid gets a bit out of hand.
We will end up having to update them from ghost before using it, so it seems like it would be better if it's moved out of the window.

Note:
after removing ghost_rect from wmWindow, I changed some code that was calling WM_check(C) to open ghost windows to call wm_window_ghostwindow_add() directly instead, so that I could specify the size of the window. It still seems to work but it's possible that this could cause problems.