-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
START /MIN WT? #9053
Labels
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
Help Wanted
We encourage anyone to jump in on these.
In-PR
This issue has a related PR
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Priority-2
A description (P2)
Product-Terminal
The new Windows Terminal.
Milestone
Comments
ghost
added
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
Needs-Tag-Fix
Doesn't match tag requirements
labels
Feb 5, 2021
Related issues, although not duplicates:
|
Yea, this is definitely unique compared to the other two. Repros easy enough. Real weird. I wonder if the OS is unhappy about us trying to set a window position when starting minimized is requested. Hard to know for sure, user32 is a mystery ¯\_(ツ)_/¯ |
zadjii-msft
added
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
Help Wanted
We encourage anyone to jump in on these.
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Priority-2
A description (P2)
Product-Terminal
The new Windows Terminal.
labels
Feb 8, 2021
DHowett
removed
the
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
label
Feb 12, 2021
4 tasks
ghost
pushed a commit
that referenced
this issue
May 6, 2022
…2979) When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc. To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable. I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues. * [x] Closes #11561 * [x] Tested manually * [x] I work here. * [x] Accidentally also closes #9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now.
ghost
added
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
and removed
In-PR
This issue has a related PR
labels
May 6, 2022
carlos-zamora
pushed a commit
that referenced
this issue
May 6, 2022
…2979) When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc. To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable. I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues. * [x] Closes #11561 * [x] Tested manually * [x] I work here. * [x] Accidentally also closes #9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now. (cherry picked from commit 14098d7) Service-Card-Id: 81599073 Service-Version: 1.14
Whoops, we reverted this but never reopened it. |
zadjii-msft
removed
the
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
label
Jul 15, 2022
zadjii-msft
added a commit
that referenced
this issue
Apr 6, 2023
…alization" (#13811) This is a revert of the revert of #12979. We mainly reverted that PR because of an issue where restored windows would grow/shrink slightly on external displays. It was too close to the ship date for that release, so we backed it out wholesale (in #13098). I think I've found the real root of the problem, and fixed it here. The money diff here from the original PR: 4c08b9a...c34495d. Basically, I had put the part where we actually handle the creation of the window into `_AppInitializedHandler`, when we should have left the window to be created in `_HandleCreateWindow` We create it there, _hidden_, and then should only _show_ it in `_AppInitializedHandler`. I'm _NOT_ incorporating the change for #9053. I reverted that bit in 1fac403. I am too worried about that messing with the phwnd that I wanted to get that reviewed and committed atomically, separately. * fixes #11561 * tested manually * I work here
microsoft-github-policy-service bot
pushed a commit
that referenced
this issue
Apr 18, 2023
…ute (#13838) Original description, pre-process model v3: > This is just the `SHOWDEFAULT` bit from #12979. This seems to also work now, but I'm PR'ing it separately so it can be a separate revert from #13811, if it is problematic. More accurately: This PR enables terminal windows to use the `wShowCmd` from the STARTUPINFO passed to `windowsterminal.exe` to set the initial visibility of the window. We can't just use `SW_SHOWDEFAULT`, because all the windows are running in the initial process! After the first window, the subsequent ones would ignore any params passed to their originating `windowsterminal.exe` processes. To mitigate, we pass that `wShowCmd` info from the source process, to the actual running terminal process. That accounts for most of the delta here. Closes #9053 This doesn't do the same for defterm-initiated connections. This is because we don't need to! Defterm very explicitly rejects handoff for minimized console apps. This is probably for the best! I put an attempt in 66f8b25 before I forgot that it was filtered long before the Terminal. NOT doing this for /min saves us all sorts of "what happens if `start /min cmd` tries to glom?" or "what if someone does `start /min cmd && start /max cmd` and they glom together?". <hr> Also closes #15193, which was introduced as a part of this. --------- Co-authored-by: Dustin L. Howett <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
Help Wanted
We encourage anyone to jump in on these.
In-PR
This issue has a related PR
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Priority-2
A description (P2)
Product-Terminal
The new Windows Terminal.
Environment
Microsoft Windows 10 Pro for Workstations
10.0.19042.746 (2009, 20H2)
WindowsTerminalPreview_1.6.10272.0_x64
Steps to reproduce
In CMD.EXE, issue
START /MIN WT
Expected behavior
WT starts minimized and can be restored.
Actual behavior
WT starts minimized and can't be restored. The taskbar icon is rather lame.
I couldn't get good pics of the taskbar icon's popup thumbnails because they close when I activate the screen clipper.
The text was updated successfully, but these errors were encountered: