Set an initial start position

[aw1875]

Allow the ability to set an initial start position from the config. Adds window-initial-position-{x,y} to the config as an optional i16 value (see swift docs in this comment for the reasoning behind this if needed) and handles setting the position when the initial window is created

Closes #3362

[jcollie]

window-initial-position-x and window-initial-position-y I think would be clearer as to their purpose.

[aw1875]

cool sounds good, I'll revert that change

[jcollie]

The should also be unsigned and optional. That way you can tell if the user did not set these in their config. Defaulting to 0,0 is probably not what users want if those settings are unspecified. 32 bits is probably too much, I think that a u16 should be fine.

[aw1875]

Correct me if I'm wrong but you can't you have negative coordinates depending on your monitor layout? I might just be mixing this up with something else but I thought that was a possibility

[jcollie]

I can't say for 100% sure, you'd need to check the documentation of the various APIs used to position the window. We definitely want these to be optional though. If the user didn't set them in the config, we don't want to force them into a specific location.

[aw1875]

I'm going to drop this here for later but macOS allows negative values (my understanding is that this value is based on your primary monitor's bottom left corner). I'll also dig into the Linux side later to see if I can find any docs supporting this behaviour.

https://developer.apple.com/documentation/appkit/nswindow/setframetopleftpoint(_:)#Discussion
https://developer.apple.com/documentation/appkit/nswindow/setframeorigin(_:)#Discussion

[mitchellh]

macOS does allow negative values to try to put the window offscreen. Various macOS settings may affect this. We can document it that it is OS dependent how that's handled.

[jcollie]

After some thinking, I think that this is the wrong approach. There shouldn't be any need to store the position in the core Surface struct or to use an apprt action to position the window. First, only the first surface that initiates the window creation should control the position of the window. If a new tab or split can affect the position of the window you'll have windows jumping back to their initial position after the user has moved them around and then creates a new tab or split.

When a new window is created it should check to see if these settings are configured and position the window at window creation time. There's no need for a message to be sent to the window at a later time.

[jcollie]

I don't program in Swift but there should be some existing machinery from macOS's state restoration that can be reused to set the initial window position from the config.

[jsejcksn]

I'm considering renaming window-position-{x,y} to start-position-{x,y} for clarity

I have no strong opinion about the name, but because existing configuration keys already use the term initial instead of start (e.g. initial-window), I suggest initial-window-position — or, as @jcollie mentioned, window-initial-position.

[aw1875]

Highlighting this note here in case a reviewer has more knowledge in the mac window space, I couldn't find anything helpful here but my hunch is this is default gap/padding/margin for NSWindow frames

[mitchellh]

I made some modifications (see my commit), but overall great job!

I renamed the config to window-position-x and y. The initial was a bit redundant there since the position is only ever relevant at start. I don't see a future where we have any other position values.

I also removed the titlebar math you had. I'm not fully sure I understood it, and the magic numbers were freaking me out. If there is a bug here in some circumstances we should open a discussion and figure that out in a more robust manner.

[mitchellh]

macOS does allow negative values to try to put the window offscreen. Various macOS settings may affect this. We can document it that it is OS dependent how that's handled.