microsoft
initialPosition should set both coordinates when one number exists
Environment
Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 0.8.10091.0
Any other software?
Steps to reproduce
Set initialPosition to "#" (any number will work).
Expected behavior
That number will set both the X and Y coordinates of the Terminal on launch. This matches the functionality of padding.
Actual behavior
Only the X coordinate gets set.
This'll be in contravention to the agreed-upon spec for launch position. We need consensus before changing it.
In a post-v1 world, I still see this as a bug and agree with @cinnamon-msft on the reasoning. Since I see it as a bug, I don't think we'd be "breaking" people.
I'll move this over to the v2 milestone for us to discuss and resolve. Especially since most of the work here is deciding on the right behavior, rather than actually implementing it.
What about?
"initialPosition": "centered"
BTW, without this "optional" option it will show in a random position each time Windows Terminal is launched.
In normal launch: as you can see in the picture above, each new window instance will be positioned in cascade and eventually some instances will show the lower part of the window hidden by the taskbar, making that part invisible when user reaches that area while writing commands, and (normally) the user will be forced to move the window.
It would be nice to consider that and detect Taskbar position and state, to conveniently position the Windows Terminal window on each launch.
I guess SHAppBarMessage ABS_ALWAYSONTOP and ABS_QUERYPOS or ABS_GETTASKBARPOS will help. However for other instances of taskbar (if enabled for another secondary monitor), I couldn't get SHAppBarMessage to work so I used EnumWindows callback to findow Shell_SecondaryTrayWnd window classname (each other taskbar instance <2nd, 3rd, etc> has that class name), to finally use GetWindowRect to find their corresponding areas occupying their respective monitors along with MonitorFromWindow.
Would it be better to use MONITORINFO::rcWork than enumerate taskbars? If this kind of thing is necessary in the first place.
Is the idea of being able to provide a single number for both options still seen as "Help wanted" and can be implemented? If so, I would take my shot at this
