<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This change cleans up the Fullscreen implementation for both conhost and Terminal, improving the restore position (where the window goes when exiting fullscreen).
Prior to this change the window wasn't guaranteed to restore somewhere on the window's current monitor when exiting fullscreen. With this change the window will restore always to its current monitor, at a reasonable location (and will 'double restore' (to fullscreen->maximize->restore) after monitor changes while fullscreen, which is the expected user behavior.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#9746
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
A fullscreen window's monitor can change.
- Win+Shift+left/right migrates a window between monitors.
- User could open settings, display, and move the monitor or change its DPI.
- The monitor could be unplugged.
- The session could be remote and be disconnected.
A fullscreen window stores a 'restore position' when entering fullscreen, used to move the window back 'where it was'. BUT, its unexpected for the window to exit fullscreen and jump to another monitor. This means its previous position must be migrated from the old monitor's work area to the new monitor's work area.
If a window is maximized, it is sized to the work area. Like with fullscreen, a maximized window has a 'restore position', though unlike with fullscreen the restore position for maximized is stored by the system itself. Migration in cases where a maximized (or fullscreen) window's monitor changes is also taken care of by the system. To restore 'safely' to maximized (after changing window styles) a window must only `SetWindowPos(SWP_FRAMECHANGED)`. While technically a maximized window that becomes fullscreen 'is still maximized' (from Win32's perspective), its prudent to also `ShowWindow(SW_MAXIMIZED)` prior to `SWP_FRAMECHANGED` (to explicitly make the window maximized).
If not restoring to maximized, the restore position is adjusted by the new/ old work area. Additionally, the new/ old window DPI is used to adjust the size of the window by the DPI change (keeping the window's logical size the same).
- The work area origin is checked first (shifting window rect by the change in origin)
- The DPI is checked next, changing right/ bottom (size only)
- Each edge of the window is compared against the corresponding edge of the work area, nudging the window back on-screen if hanging offscreen. By shifting right before left, bottom before top, the top-left is guaranteed on-screen.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Tried it out. Seemed to work on my machine.
Jk, ran conhost/ terminal on mixed DPI system, max (or not), fullscreen, win+shift+left/ exit fullscreen/ maximize. Monitor unplug, etc.
## Summary of the Pull Request
This PR adds support for renaming windows.
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
## Summary of the Pull Request
This is a follow up to #9300. Now that we have names on our windows, it would be nice to see who is named what. So this adds two actions:
* `identifyWindow`: This action will pop up a little toast (#8592) displaying the name and ID of the window, and is bound by default.
* `identifyWindows`: This action will request that ALL windows pop up that toast. This is meant to feel like the "Identify" button on the Windows display settings. However, sometimes, it's wonky.
That's being tracked upstream on https://github.com/microsoft/microsoft-ui-xaml/issues/4382
Because it's so wonky, we won't bind that by default. Maybe if we get that fixed, then we'll change the default binding from `identifyWindow` to `identifyWindows`
## References
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-51431492
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
You may note that there are some macros to make interacting with lots and lots of actions easier. There's a lot of boilerplate whenever you need to make a new action, so I thought: "Can we make that easier?"
Turns out you can make it a _LOT_ easier, but that work is still behind another PR after this one. Get excited
**BE NOT AFRAID**. I know that there's 107 files in this PR, but almost
all of it is just find/replacing `TerminalControl` with `Control`.
This is the start of the work to move TermControl into multiple pieces,
for #5000. The PR starts this work by:
* Splits `TerminalControl` into separate lib and dll projects. We'll
want control tests in the future, and for that, we'll need a lib.
* Moves `ICoreSettings` back into the `Microsoft.Terminal.Core`
namespace. We'll have other types in there soon too.
* I could not tell you why this works suddenly. New VS versions? New
cppwinrt version? Maybe we're just better at dealing with mdmerge
bugs these days.
* RENAMES `Microsoft.Terminal.TerminalControl` to
`Microsoft.Terminal.Control`. This touches pretty much every file in
the sln. Sorry about that (not sorry).
An upcoming PR will move much of the logic in TermControl into a new
`ControlCore` class that we'll add in `Microsoft.Terminal.Core`.
`ControlCore` will then be unittest-able in the
`UnitTests_TerminalCore`, which will help prevent regressions like #9455
## Detailed Description of the Pull Request / Additional comments
You're really gonna want to clean the sln first, then merge this into
your branch, then rebuild. It's very likely that old winmds will get
left behind. If you see something like
```
Error MDM2007 Cannot create type
Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata
file Microsoft.Terminal.TerminalControl.
```
then that's what happened to you.
This finishes the implementation of `--window` to also accept a string
as the "name" of the window. So you can say
```sh
wt -w foo new-tab
wt -w foo split-pane
```
and have both those commands execute in the same window, the one named
"foo". This is just slightly more ergonomic than manually using the IDs
of windows. In the future, I'll be working on renaming windows, and
displaying these names.
> #### `--window,-w <window-id>`
> Run these commands in the given Windows Terminal session. This enables opening
> new tabs, splits, etc. in already running Windows Terminal windows.
> * If `window-id` is `0`, run the given commands in _the current window_.
> * If `window-id` is a negative number, or the reserved name `new`, run the
> commands in a _new_ Terminal window.
> * If `window-id` is the ID or name of an existing window, then run the
> commandline in that window.
> * If `window-id` is _not_ the ID or name of an existing window, create a new
> window. That window will be assigned the ID or name provided in the
> commandline. The provided subcommands will be run in that new window.
> * If `window-id` is omitted, then obey the value of `windowingBehavior` when
> determining which window to run the command in.
Before this PR, I think we didn't actually properly support assigning
the id with `wt -w 12345`. If `12345` didn't exist, it would make a new
window, but just assign it the next id, not assign it 12345.
## References
* #4472, #8135
* https://github.com/microsoft/terminal/projects/5
## Validation Steps Performed
Ran tests
Messed with naming windows, working as expected.
Closes https://github.com/microsoft/terminal/projects/5#card-51431478
This PR is a resurrection of #8414. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.
This PR adds new global setting `centerOnLaunch`. When set to `true`,
the Terminal window will be centered on the display it opens on.
So the interactions are like:
* `initialPos: x,y`, `centered: true`, `launchMode: default`
center on the monitor that x,y is on
* `initialPos: x,y`, `centered: true`, `launchMode: maximized`
maximized on the monitor that x,y is on (centered adds nothing)
* `initialPos: <omitted>`, `centered: true`, `launchMode: default`
center on the default monitor
* `initialPos: <omitted>`, `centered: true`, `launchMode: focus`
center, focus mode on the default monitor
* `initialPos: <omitted>`, `centered: true`, `launchMode: maximized`
maximized on the default monitor (centered adds nothing)
## Validation Steps Performed
I've played with it on multiple different monitors, and it seems to work
on all of them.
Closes#8414 (original PR)
Closes#7722
Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
Adds support for the `windowingBehavior` global setting. This setting
controls how mutiple instances of `wt` behave in the absence of the `-w`
parameter. This setting has three values:
* `"useNew"`: (default) Multiple `wt` invocations (without the `-w`
param) always create new windows.
* `"useAnyExisting"`: When starting a new `wt`, we'll instead default to
any existing windows. `wt -w -1` will still create new windows.
* `"useExisting"`: Similar to `useAnyExisting`, but limits to
windows on the current desktop.
The IVirtualDesktopManager interface is _very_ limited. Hence why we
have to track the HWNDs manually, and ask if they're on the current
desktop.
## Validation Steps Performed
I've been playing with it for a week now.
References #5000
References projects/5
References #8898
Spec'd in #8135Closes#2227
Closes https://github.com/microsoft/terminal/projects/5#card-51431448
Closes https://github.com/microsoft/terminal/projects/5#card-51431433
This will make sure to summon the terminal window when running a
commandline in it.
* If the window is on another desktop, the OS will switch to the desktop
the window is on.
* If the window is minimized, it will restore it.
This is taken from my quake mode branch. It works aggressively. 848682a,
fee6473, 342d3f2, 5052d31 all had other attempts at doing this, but they
didn't work reliably. Part of the trick is that I don't _think_ Windows
wants one process to be able to move another process into the
foreground. In this case though, we _do_ want to move ourself into the
foreground, and this `AttachThreadInput` hack seems to be the only way
to do it reliably.
References #5000
Uses code authored for #653
Closes https://github.com/microsoft/terminal/projects/5#card-54636373
## Summary of the Pull Request
**If you're reading this PR and haven't signed off on #8135, go there first.**
This provides the basic parts of the implementation of #4472. Namely:
* We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window.
* If `window-id` is `0`, run the given commands in _the current window_.
* If `window-id` is a negative number, run the commands in a _new_ Terminal window.
* If `window-id` is the ID of an existing window, then run the commandline in that window.
* If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window.
* If `window-id` is omitted, then create a new window.
## References
* Spec: #8135
* Megathread: #5000
* Project: projects/5
## PR Checklist
* [x] Closes#4472
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - **sure does**
## Detailed Description of the Pull Request / Additional comments
Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change
There are limitations, and there are plenty of things to work on in the future:
* [ ] We don't support names for windows yet
* [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that.
* [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from.
* [ ] Basically anything else that's listed in projects/5.
I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in.
## Validation Steps Performed
I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain.
# TODOs
* [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬
- [x] `Monarch.cpp`
- [x] `Peasant.cpp`
- [x] `WindowManager.cpp`
- [x] `AppHost.cpp`
* [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully.
- Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID.
- Could we gracefully recover from such a state? maybe, probably not though.
- Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant?
- After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
### Plurals and paste tenses
In the past, plurals `foo`+`s` and past tenses `foo`+`ed` were
automatically tolerated. This turned out to be a bad design choice on my
part.
The basic example is that `potatos` would sometimes be treated as a
mistake and sometimes not (depending on the presence of `potato`).
You can see in this PR, that this logic resulted in `Applys` being
accepted as a word along with `AppContainered` -- there's nothing
intrinsically wrong w/ the latter, but unfortunately in order to screen
out the former, my shortcut just couldn't stick around. This means that
the `dictionary`/`expect` files will grow perhaps by a tiny bit, but as
you can see, not really by much.
This is also why `thereses` (a user) was accepted as a word in the past
(therese is in the base dictionary, so `therese` + `s` was acceptable).
### Pull requests
When GitHub initially introduced GitHub Actions, the event for
`pull_request` was created without enough permission for a tool like
this to work properly. I worked around that by using the `schedule`
event. In 2020, they introduced a replacement event
`pull_request_target` which has enough permission. This means that I can
stop relying on the `schedule` event.
### Miscellaneous
* I've folded together some `expect/` files since now is as good a time
as any.
* I've included a hint about `excludes.txt` (I added a similar one for
our primary repo recently, and it came up this week in
`microsoft/terminal` -- @zadjii-msft)
* I've standardized on a default of `.github/actions/spelling` to make
the out of the box experience easier for new adopters, so I'm applying
that change here -- if you're attached to the old directory name,
specifying it is still supported. -- note the directory rename may
cause a merge conflict for people with open PRs and changes to the
contents, this shouldn't be a big problem.
Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will
be responsible for all the Monarch/Peasant work that's been described in
#7240 & #8135.
This PR does _not_ implement the Monarch/Peasant architecture in any
significant way. The goal of this PR is to just to establish the project
layout, and the most basic connections. This should make reviewing the
actual meat of the implementation (in a later PR) easier. It will also
give us the opportunity to include some of the basic weird things we're
doing (with `CoRegisterClass`) in the Terminal _now_, and get them
selfhosted, before building on them too much.
This PR does have windows registering the `Monarch` class with COM. When
windows are created, they'll as the Monarch if they should create a new
window or not. In this PR, the Monarch will always reply "yes, please
make a new window".
Similar to other projects in our solution, we're adding 3 projects here:
* `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a
static lib.
* `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL,
for use in `WindowsTerminal.exe`.
* `Remoting.UnitTests.dll`: A unit test dll that links with the static
lib.
There are plenty of TODOs scattered about the code. Clearly, most of
this isn't implemented yet, but I do have more WIP branches. I'm using
[`projects/5`](https://github.com/microsoft/terminal/projects/5) as my
notation for TODOs that are too small for an issue, but are part of the
whole Process Model 2.0 work.
## References
* #5000 - this is the process model megathread
* #7240 - The process model 2.0 spec.
* #8135 - the window management spec. (please review me, I have 0/3
signoffs even after the discussion we had 😢)
* #8171 - the Monarch/peasant sample. (please review me, I have 1/2)
## PR Checklist
* [x] Closes nothing, this is just infrastructure
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
This commit iontroduces another `target` to the `openSettings` binding:
`settingsUI`. It opens the settings UI introduced in the previous
commit.
Closes#1564Closes#8048 (PR)
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Leon Liang <lelian@microsoft.com>
This PR defines a series of `NOSOMETHING` macros in PCHs, in order to
prevent `windows.h` from bringing a lot of rarely used things into the
project.
Theoretically this should make PCH generation and overall complication
faster, but I didn't really benchmark the speed.
Another benefit would be reducing the symbol noises caused by
`windows.h`.
There's a handful of small changes in these updates:
The Win32 Toolkit is now built with CFG (I think), and
the VCRT forwarders are now the (second) non-RC version.
This commit moves us to the Xaml prerelease (201202003) that is
equivalent to public stable release 2.5.
Remember, we need to use prereleases for some silly reason.
This fixes the issue with the settings UI where clicking the browse
buttons would cause an exception to be thrown when we tried to display a
picker without an originating HWND.
It turns out that pickers need a hosting/parent window, and Xaml Islands
doesn't furnish us with a CoreWindow that's set up for that use case.
Alas!
Raymond Chen's [blog post on the matter] suggests that we should
hand the HWND off through some classic COM interface. To do that
properly, Terminal's various components need to implement that interface
and propagate the HWND down where it's needed.
Thanks to a [Xaml compiler issue], we can't actually do that. To work
around that, we've begged and borrowed different methods for pushing
HWNDs around:
1. Using IInitializeWithWindow in secret
2. A member that takes a uint64
3. An interface that offers a function that will "wire up" the HWND.
I chose (1) because AppHost can implement IInitializeWithWindow, but
TerminalPage cannot. We're just pretending that TerminalPage _can_.
I chose (2) because none of the Xaml types in TerminalSettingsEditor can
implement the interface thanks to the aforementioned compiler issue, but
we don't have an escape hatch like AppHost that lives in the same module
and can help us do the propagation.
I chose (3) because I didn't want to commit the same sin as (2) _seven
times_ for every different type of settings page that exists. (3) is
backed by "IHostedInWindow", and anybody who knows they have to use
IInitializeWithWindow to tie an HWND to an object can call
IHostedInWindow.TryPropagateHostingWindow() on that object.
House of cards.
[Xaml compiler issue]: https://github.com/microsoft/microsoft-ui-xaml/issues/3331
[blog post on the matter]: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413
(cherry picked from commit f9fc9861a1)
Many include statements use forward slashes, while others use backwards
slashes. This is inconsistent formatting. For this reason, I changed the
backward slashes to forward slashes since that is the standard.
The terminal taskbar icon can now flash when the BEL sequence is
emitted, to let the user know something needs their attention.
The `BellStyle` setting can now be set to `audible`, `visual` or both or
none. When the pane receives a BEL event and the `bellStyle` includes
`visual`, we bubble the event up all the way to `AppHost` to handle
flashing the taskbar.
Closes#1608
This commit implements the OSC 9;4 sequence per the [ConEmu style].
| sequence | description |
| ------------ | ------------ |
| `ESC ] 9 ; 4 ; st ; pr ST` | Set progress state on taskbar and tab. |
| | When `st` is: |
| | |
| | `0`: remove progress. |
| | `1`: set progress value to `pr` (number, 0-100). |
| | `2`: set the taskbar to the "Error" state |
| | `3`: set the taskbar to the "Indeterminate" state |
| | `4`: set the taskbar to the "Warning" state |
We've also extended this with:
* st 3: set indeterminate state
* st 4: set paused state
We handle multiple tabs sending the sequence by using the the last focused
control's taskbar state/progress.
Upon receiving the sequence in `TerminalApi`, we send an event that gets caught
by `TerminalPage`. `TerminalPage` then fires another event that gets caught by
`AppHost` and that's where we set the taskbar progress.
Closes#3004
[ConEmu style]: https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
Until now, we relied on WM_SIZING to ensure that the island is not
downsized below minimal allowed dimensions. However, on some occasions
WM_WINDOWPOSCHANGED, e.g. when anchoring a window to the top/bottom of
the screen. This message will use dimensions obtained from
WM_GETMINMAXINFO. Until now we didn't override this value, falling back
to the defaults. As a result we got an inconsistent behavior (at least
when attaching the anchor).
I added logic very similar to the one we use in IslandWindow::_OnSizing
to the MINMAXINFO handler: snap the client area, add non client
exclusive are, consider DPI along the computation.
## Validation Steps Performed
* Manual testing of minimizing, maximizing, resizing, attaching
different anchors, etc.
Closes#8026
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
In the focus mode the top border disappears upon resize. While this behavior is expected in the maximized / full screen mode, it should not happen in the focus mode.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/7012
* [x] CLA signed
* [ ] Tests added/passed - nope, only manual testing
* [ ] Documentation updated - irrelevant
* [ ] Schema updated - irrelevant
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
_GetTopBorderHeight method returns 0 when maximized or no title bar is visible. However the existence of top border has nothing to do with whether the title bar is visible. We want to leave the border as long as the window is not in some form of maximizing (maximized / full screen)
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
* Manual - dragging, resizing, maximizing both in focus and non focus modes + full screen testing
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/7996
* [x] CLA signed.
* [ ] Documentation updated - irrelevant
* [ ] Schema updated - irrelevant
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Currently the value of AlwaysOnTop is read by the AppHost from AppLogic that takes this value from the root TerminalPage. However at this stage neither AppLogic nor TerminalPage are initialized, and thus the return value is always false.
This PR introduces a "GetInitialAlwaysOnTop" method to AppLogic that returns a value that is configured in the settings.
In addition, the TerminalPage creation was fixed to read the configuration value upon creation (and not just after settings reload).
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
* Only manual testing
* Starting the system with both initial value set to true and false
* Verifying that dynamic toggling on / off is not affected
This commit introduces 8 more variants of the .ICO file, embeds the
right ones into WindowsTerminal.exe, and adds code that will select the
most appropriate icon at runtime.
Since we're a Centennial application, the "application" icon inside our
package isn't used by the shell for the taskbar thumbnails or the
Alt-Tab window.
To quote J. Tippet,
> I believe there are two possible fixes:
>
> 1. Fix the OS shell to prefer the MRT icon instead of preferring the
> win32 icon
> 2. Add alternate versions of /res/terminal.ico
> The 1st fix is clearly better, since it benefits any hybrid app. But
> the 2nd fix is much easier, since it'd just take about an hour to gin up
> a new .ico file and hack the .RC file to refer to it when building the
> preview flavor.
... and to quote Michael Ratanapintha,
> Basically, if your MSIX-packaged desktop app's image resources are
> separate files or even separate MSIX packages, they may be loaded by
> MRT. If they're embedded in the .exe, they're the old-fashioned Win32
> resources Mr. Tippet is referring to.
This is the "2nd fix."
Fixes#6777
Co-authored-by: Jeffrey Tippet <jtippet@ntdev.microsoft.com>
This commit fixes our longstanding build artifact output issues and
finally unifies all C++ project output into bin/ and obj/.
In light of that, I've removed NoOutputRedirection.
I've also updated WTU and U8U16Test to use our common build props and
fixed any warnings/compilation errors that popped out.
I validated this change by running repeated incremental builds after
changing individual .cpp files in many of our C++/WinRT projects.
Our build pipeline was originally set up such that we could take any
binaries from the Terminal build and seamlessly re-package them with the
release or preview livery. My initial plan was to stamp a stable and
preview build at the same time, out of the same bits, to make ring
promotion easier.
I've never done that. For the last five releases, we've just re-cut a
new stable build along with the new preview build, usually because we
want to backport some fixes to stable.
This commit introduces preprocessor defines, detectable through CL and
RC, for any project that wants them. Right now, that's just going to be
WindowsTerminal.vcxproj (since it hosts the icons and the app entry
point). This list may be extended to include wt (the shim executable)
and the shell extension at some future date.
This will greatly simplify the logic in #7971, as we'll no longer need
to detect if we're dev or preview at runtime. It may also simplify the
logic in the shell extension for determining whether we're Dev or not.
This commit introduces two new launch modes: focus and maximizedFocus.
* Focused mode, behaves like a default mode, but with the Focus Mode
enabled.
* Maximized focused mode, behaves like a Maximized mode, but with the
Focus Mode enabled.
There two ways to invoke these new modes:
* In the settings file: you set the "launchMode" to either "focus" or
"maximizedFocus"
* In the command line options, you can path -f / --focus, which is
mutually exclusive with the --fullscreen, but can be combined with the
--maximized:
* Passing -f / --focus will launch the terminal in the "focus" mode
* Passing -fM / --focus --maximized will launch the terminal in the
"maximizedFocus" mode
This should resolve a relevant part in the command line arguments
mega-thread #4632Closes#7124Closes#7825Closes#7875
Took this as an easy starter. The method IslandWindow::SetAlwaysOnTop is
triggered once terminal settings are reloaded (in
TerminalPage::_RefreshUIForSettingsReload flow). This method calls
SetWindowPos without SWP_NOACTIVATE. As a result the window gets
activated, the focus is set and the cursor starts blinking.
Added SWP_NOACTIVATE in all SetWindowPos calls from IslandWindow and
NoClientIslandWindow (where it was missing). Please let me know if this
is an overkill - it is not required to fix the issue, however seems a
good practice, that might help if we decide to apply more settings
immediately.
## Validation Steps Performed
* Only manual testing - please guide me to the relevant UT framework, if
exists.
* Trying to reproduce this with VS attached doesn't work - the window
gets the focus in any case.
* Tested as a standalone application, by modifying different settings
(and comparing the results before and after the fix).
* Checked with Spy++ that no WM_ACTIVATE / WM_SETFOCUS is thrown upon
settings modification
* Applied terminal resizing, toggling full screen and focus mode to
check no regression was introduced.
Closes#7571
This pull request introduces (a very, very stripped-down copy of) the
WIL fallback error reporter.
It emits error records, usually immediately before the application
implodes, into the event stream.
This should improve diagnosability of issues that take Terminal down,
and allow us to give out a .wprp file to gather traces from users.
Introduces a new TerminalSettingsModel (TSM) project. This project is
responsible for (de)serializing and exposing Windows Terminal's settings
as WinRT objects.
## References
#885: TSM epic
#1564: Settings UI is dependent on this for data binding and settings access
#6904: TSM Spec
In the process of ripping out TSM from TerminalApp, a few other changes
were made to make this possible:
1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was
moved to `CascadiaSettings`
- These are defined as static functions. They also no longer check if
`AppLogic::Current()` is nullptr.
2. `enum LaunchMode` was moved from TerminalApp to TSM
3. `AzureConnectionType` and `TelnetConnectionType` were moved from the
profile generators to their respective TerminalConnections
4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are
exposed as `hstring` instead of `std::filesystem::path`
5. `Command::ExpandCommands()` was exposed via the IDL
- This required some of the warnings to be saved to an `IVector`
instead of `std::vector`, among some other small changes.
6. The localization resources had to be split into two halves.
- Resource file linked in init.cpp. Verified at runtime thanks to the
StaticResourceLoader.
7. Added constructors to some `ActionArgs`
8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to
`JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp.
A large amount of work includes moving to the new namespace
(`TerminalApp` --> `Microsoft::Terminal::Settings::Model`).
Fixing the tests had its own complications. Testing required us to split
up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a
non-local test variant can be found in #7743.
Closes#885
The WAP packaging project is sensitive to including applications that it
thinks are UWPs. The changes we made to separate WindowsStoreApp and
WindowsAppContainer weren't comprehensive enough to convince WAP that we
were not still UWPs.
Because of that, it would run sub-builds of each of these projects (and
all their dependencies) with an additional `GenerateAppxPackageOnBuild`
property set. The existence of this property caused MSBuild to think the
projects needed to be built *again*.
GlobalAppSettings is now a WinRT object in the TerminalApp project.
## References
#7141 - GlobalAppSettings is a settings object
#885 - this new settings object will be moved to a new TerminalSettingsModel project
## PR Checklist
* [x] Tests passed
## Detailed Description of the Pull Request / Additional comments
This one was probably the easiest thus far.
The only weird thing is how we handle InitialPosition. Today, we lose a
little bit of fidelity when we convert from LaunchPosition (int) -->
Point (float) --> RECT (long). The current change converts
LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT
(long).
NOTE: Though I could use LaunchPosition to go directly from TermApp to
AppHost, I decided to introduce InitialPosition because LaunchPosition
will be a part of TerminalSettingsModel soon.
## Validation Steps Performed
- [x] Tests passed
- [x] Deployment succeeded
The easiest fix was actually just moving all the source files from
`TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h`
actually resides.
Closes#6866
#7145 introduced a check so that we wouldn't dispatch keys unless they
actually had a scancode. Our synthetic events actually _didn't_ have
scancodes. Not because they couldn't--just because they didn't.
Fixes#7297
## Summary of the Pull Request
This PR adds support for both _nested_ and _iterable_ commands in the Command palette.
* **Nested commands**: These are commands that include additional sub-commands. When the user selects on of these, the palette will update to only show the nested commands.
* **Iterable commands**: These are commands what allow the user to define only a single command, which is repeated once for every profile. (in the future, also repeated for color schemes, themes, etc.)
The above gif uses the following json:
```json
{
"name": "Split Pane...",
"commands": [
{
"iterateOn": "profiles",
"name": "Split with ${profile.name}...",
"commands": [
{ "command": { "action": "splitPane", "profile": "${profile.name}", "split": "automatic" } },
{ "command": { "action": "splitPane", "profile": "${profile.name}", "split": "vertical" } },
{ "command": { "action": "splitPane", "profile": "${profile.name}", "split": "horizontal" } }
]
}
]
},
```
## References
## PR Checklist
* [x] Closes#3994
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - Sure does, but we'll finish polishing this first.
## Detailed Description of the Pull Request / Additional comments
We've now gotta keep the original json for a command around, so that once we know what all the profiles will be, we can expand the commands that need it.
We've also got to parse commands recursively, because they might have any number of child commands.
These together made the command parsing a _lot_ more complicated, but it feels good so far.
## Validation Steps Performed
* wrote a bunch of tests
* Played with it a bunch
MouseInput was directly asking user32 about the state of the mouse buttons,
which was somewhat of a layering violation. This commit makes all callers
have to pass the mouse state in themselves.
Closes#4869
## Summary of the Pull Request
Move `ICoreSettings` and `IControlSettings` from the TerminalSettings project to the TerminalCore and TerminalControl projects respectively. Also entirely removes the TerminalSettings project.
The purpose of these interfaces is unchanged. `ICoreSettings` is used to instantiate a terminal. `IControlSettings` (which requires an `ICoreSettings`) is used to instantiate a UWP terminal control.
## References
Closes#7140
Related Epic: #885
Related Spec: #6904
## PR Checklist
* [X] Closes#7140
* [X] CLA signed
* [X] Tests ~added~/passed (no additional tests necessary)
* [X] ~Documentation updated~
* [X] ~Schema updated~
## Detailed Description of the Pull Request / Additional comments
A lot of the work here was having to deal with winmd files across all of these projects. The TerminalCore project now outputs a Microsoft.Terminal.TerminalControl.winmd. Some magic happens in TerminalControl.vcxproj to get this to work properly.
## Validation Steps Performed
Deployed Windows Terminal and opened a few new tabs.
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
This PR adds support for always on top mode, via two mechanisms:
* The global setting `alwaysOnTop`. When set to true, the window will be
created in the "topmost" group of windows. Changing this value will
hot-reload whether the window is in the topmost group.
* The action `toggleAlwaysOnTop`, which will toggle the `alwaysOnTop`
property at runtime.
## Detailed Description of the Pull Request / Additional comments
All "topmost" windows maintain an internal z-ordering relative to one
another, but they're all always above all other "non-topmost" windows.
So multiple Windows Terminal windows which are both `alwaysOnTop` will
maintain a z-order relative to one another, but they'll all be on top of
all other windows.
## Validation Steps Performed
Toggled always on top mode, both in the settings and also at runtime,
and verified that it largely did what I expected.
Closes#3038
## Summary of the Pull Request
Add support for "focus" mode, which only displays the actual terminal content, no tabs or titlebar. The edges of the window are draggable to resize, but the window can't be moved in borderless mode.
The window looks _slightly_ different bewteen different values for `showTabsInTitlebar`, because switching between the `NonClientIslandWindow` and the `IslandWindow` is _hard_.
`showTabsInTitlebar` | Preview
-- | --
`true` | 
`false` | 
## PR Checklist
* [x] Closes#2238
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
* **KNOWN ISSUE**: Upon resizing the NCIW, the top frame margin disappears, making that border disappear entirely. 6356aaf has a bunch of WIP work for me trying to fix that, but I couldn't get it quite right.
## Validation Steps Performed
* Toggled between focus and fullscreen a _bunch_ in both modes.
The main change in 16.7 is the separation of `AppContainerApplication`
into `WindowsStoreApp` and `WindowsAppContainer`. There's been a bit of
interest in splitting packaging away from containment, and this is the
first step in that direction.
We're a somewhat unique application, but as WinUI3 becomes more
prevalent we will become _less_ unique.
Some of these things, I've looked at and wondered how they ever worked.
## PR Checklist
* [x] Closes nothing
## Validation Steps Performed
Built locally and in CI. Tested the generated package with the package tester. Built on 16.6 and seen that it still seems to work.
See: https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.200609001
> ### Notable Changes:
>
> Resize tab view items only once the pointer has left the TabViewItem strip (microsoft/microsoft-ui-xaml#2569)
> Align TabView visuals with Edge (microsoft/microsoft-ui-xaml#2201)
> Fix background of MenuFlyout in white high contrast (microsoft/microsoft-ui-xaml#2446)
> TabView: Make TabViewItem consume the TabViewItemHeaderForeground theme resource (microsoft/microsoft-ui-xaml#2348)
> TabView: Add tooltips to its scrolling buttons. (microsoft/microsoft-ui-xaml#2369)
* [x] Related to #5360 (@jtippet confirms that this alone does not close it.)
* [x] I work here
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Many places in this codebase has an equality comparison to the boolean FALSE. This adds unneeded complexity as C and C++ has a NOT operand for use of these in if statements. This makes the code more readable in those areas.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [X] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
One boolean being compared to FALSE was only used once, with the boolean name being "b", so it is better off not existing at all.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Unit Testing passed, compiler refactoring
For mysterious reasons lost to the sands of time, XAML will _never_ pass
us a VK_MENU event. This is something that'll probably get fixed in
WinUI 3, but considering we're stuck on system XAML for the time being,
the only way to work around this bug is to pass the event through
manually. This change generalizes the F7 handler into a "direct key
event" handler that uses the same focus and tunneling method to send
different key events, and then uses it to send VK_MENU.
## Validation Steps Performed
Opened the debug tap, verified that I was seeing alt key ups.
Also used some alt keybindings to make sure I didn't break them.
Closes#6421
This pull request moves WindowUiaProvider back into Win32 interactivity
and deletes all mention of it from Windows Terminal. Terminal does not
have a single toplevel window that requires Console-like UIA, as each
Xaml control inside it is in charge of its own destiny.
I've also merged `IUiaWindow` and `IConsoleWindow` back together, as
well as `WindowUiaProviderBase` and `WindowUiaProvider`.
Things look a lot more like they did before we tore them apart.
## PR Checklist
* [x] Closes#3564
* [x] CLA
* [x] Tests added/passed (manual)
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already
## Validation
Carlos validated conhost and terminal on this branch.
Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must
be generated by targets.
We mostly use wildcards for pulling in PRI files that are dumped on disk
by the translation tool. We don't want to check those in, so we can't
expand references to them.
To that end, I've introduced a new target that will take a list of
folders containing resw files and expand wildcards under them.
All[1] other wildcards have been moved into their respective targets
_or_ simply expanded.
[1]: Nothing has complained about the resource wildcards in
CascadiaResources.build.items, so I haven't exploded it yet.
Fixes#6214.
This brings support for "Compact" tab sizing, which compresses all inactive tabs to just the size of their icons plus the close button. Neat!
It also just keeps us generally up-to-date and good citizens.
## Summary of the Pull Request
Adds `"launchMode": "fullscreen"`, which does what it says on the box.
## PR Checklist
* [x] Closes#288
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
It's important to let the winow get created, _then_ fullscreen it, because otherwise, when the user exits fullscreen, the window is sized to like, 0x0 or something, and that's just annoying.
## Summary of the Pull Request
This is an enormously trivial nit - when we launch maximized, we don't draw the maximize button in the "restore" state.
This PR changes the terminal to manually update the Maximize button on launch, once the titlebar is added to the UI tree.
## PR Checklist
* [x] Closes#3440
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
This pull request moves swaths of Cascadia to use `til::color` for color
interop. There are still some places where we use `COLORREF`, such as in
the ABI boundaries between WinRT components.
I've also added two more til::color helpers - `with_alpha`, which takes
an existing color and sets its alpha component, and a
`Windows::UI::Color` convertor pair.
Future direction might include a `TerminalSettings::Color` type at the
idl boundary so we can finally stop using UInt32s (!) for color.
## Validation Steps Performed
Tested certain fragile areas:
* [x] setting the background with OSC 11
* [x] setting the background when acrylic is in use (which requires
low-alpha)
## Summary of the Pull Request
This adds a new appxmanifest for 'Windows Terminal (Preview)' and links the resources.
Code-wise, split up `WindowsTerminalReleaseBuild` into...
- WindowsTerminalOfficialBuild: [true, false]
- WindowsTerminalBranding: [Dev, Preview, Release]
Added a comment about that in release.yml
## Validation Steps Performed
used msbuild to build...
- [X] Dev
- [X] Preview
- [X] Release
then checked the msix for the correct name/icon.
We've got a weird crash that happens terribly inconsistently, but pretty
readily on migrie's laptop, only in Debug mode. Apparently, there's some
weird ref-counting magic that goes on during teardown, and our
Application doesn't get closed quite right, which can cause us to crash
into the debugger. This of course, only happens on exit, and happens
somewhere in the `...XamlHost.dll` code.
Crazily, if we _manually leak the `Application`_ here, then the crash
doesn't happen. This doesn't matter, because we really want the
Application to live for _the entire lifetime of the process_, so the only
time when this object would actually need to get cleaned up is _during
exit_. So we can safely leak this `Application` object, and have it just
get cleaned up normally when our process exits.
* [x] I discussed this with @DHowett-MSFT and we both agree this is mental
* [x] I'm pretty sure there's not an actual bug on our repo for this
* [x] I verified on my machine where I can crash the terminal 100% of the time on exit in debug, this fixes it
* [x] I verified that it doesn't introduce a _new_ crash in Release on my machine
For our release builds, we're just going to integrate the UWPDesktop CRT
into our package and delete the package dependencies. It's very
difficult for users who do not have access to the store to get our
dependency packages, and we want to be robust and deployable everywhere.
Since these libraries can be redistributed, it's easiest if we simply
redistribute them.
Our package grows by ~550kb per architecture (compressed) because of
this. I've added validation that we don't have both the libs _and_ the
dependencies in the same package.
Fixes#3097.
## Validation
The script does it!
Also known as "Kill HRGN II: Kills Regions Dead (#5485)"
Copying the description from @greg904 in #4778.
--- 8< ---
My understanding is that the XAML framework uses another way of getting
mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It
looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`.
Before, we were cutting (with `HRGN`s) the drag bar part of the XAML
islands window in order to catch mouse messages and be able to implement
the drag bar that can move the window. However this "cut" doesn't only
apply to input (mouse messages) but also to the graphics so we had to
paint behind with the same color as the drag bar using GDI to hide the
fact that we were cutting the window.
The main issue with this is that we have to replicate exactly the
rendering on the XAML drag bar using GDI and this is bad because:
1. it's hard to keep track of the right color: if a dialog is open, it
will cover the whole window including the drag bar with a transparent
white layer and it's hard to keep track of those things.
2. we can't do acrylic with GDI
So I found another method, which is to instead put a "drag window"
exactly where the drag bar is, but on top of the XAML islands window (in
Z order). I've found that this lets us receive the `WM_LBUTTONDOWN`
messages.
--- >8 ---
Dustin's notes: I've based this on the implementation of the input sink
window in the UWP application frame host.
Tested manually in all configurations (debug, release) with snap,
drag, move, double-click and double-click on the resize handle. Tested
at 200% scale.
Closes#4744Closes#2100Closes#4778 (superseded.)
If Terminal is spawned by a shortcut that requests that it run in a new process group
while attached to a console session, that request is nonsense. That request will, however,
cause WT to start with Ctrl-C disabled. This wouldn't matter, because it's a Windows-subsystem
application. Unfortunately, that state is heritable. In short, if you start WT using cmd in
a weird way, ^C stops working inside the terminal. Mad.
Fixes#5460.
## Summary of the Pull Request
When we're restoring from minimized, that `MonitorFromWindow` call is returning null. Curious that we're getting null here, when [MSDN states](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-monitorfromwindow):
> If the window is currently minimized, MonitorFromWindow uses the rectangle of the window before it was minimized.
Turns out, `MONITOR_DEFAULTTONEAREST` just fixes this.
## References
* #4857 - original PR that added this code block
## PR Checklist
* [x] Closes#5209
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Verified manually
## Summary of the Pull Request
As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads).
This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content.
Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal.
## References
* #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML
## PR Checklist
* [x] Closes#979
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point`
## Validation Steps Performed
* It works on my HP Spectre 2017 with a synaptics trackpad
- I also made sure to test that `tmux` works in panes on this laptop
* It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
This commit introduces a github action to check our spelling and fixes
the following misspelled words so that we come up green.
It also renames TfEditSes to TfEditSession, because Ses is not a word.
currently, excerpt, fallthrough, identified, occurred, propagate,
provided, rendered, resetting, separate, succeeded, successfully,
terminal, transferred, adheres, breaks, combining, preceded,
architecture, populated, previous, setter, visible, window, within,
appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing,
prioritized, aforementioned, check in, build, filling, indices, layout,
mapping, trying, scroll, terabyte, vetoes, viewport, whose
## Summary of the Pull Request
One of our great contributors already hooked up all the logic for this,
we just needed a theme library that could handle the request.
## PR Checklist
* [x] Fixes#4980
* [x] CLA signed
* [x] Tests added/passed
* [ ] Requires documentation to be updated
This commit upgrades C++/WinRT to 2.0.200316.3 and fixes a couple of the
transitive dependency issues we had in the process.
Because the latest version has better dependency resolution, we're able
to properly depend on Microsoft.UI.Xaml and the Toolkit in TerminalApp
and TerminalAppLib so we no longer need to manually include .dll and
.pri files.
Because of nebulous _other_ changes in dependency resolution,
WindowsTerminalUniversal isn't picking up transitive .winmd dependencies
from TerminalApp, and needs to include them as ProjectReferences
directly. This was already happening transitively, so now it's explicit.
I've also taken the time to upgrade GSL to v2.1.0, the last release
before they removed span::at and blew up our world.
## Summary of the Pull Request
When the auto-hide taskbar setting is enabled, then we don't
always get another window message to trigger us to remove the drag bar.
So, make sure to update the size of the drag region here, so that it
_definitely_ goes away.
## References
## PR Checklist
* [x] Closes#4224
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Manually tested it
## Summary of the Pull Request
This fixes our calculation for the initial size of the window. WE weren't accounting for the height of the tabs, so the `initialRows` was consistently wrong.
## PR Checklist
* [x] Closes#2061
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
For the tabs below the titlebar case, there's 6px (unscaled) of space that I cannot account for. I seriously have no idea where it's coming from. When we end up creating the first `TermControl` after startup, there's an inexplicable `6*scale` difference between the height of the `tabContent` and the `SwapChainPanel`'s size.
## Validation Steps Performed
Checked all six of the following cases:
* 1.0 DPI scaling, Tabs in Titlebar
* 1.25 DPI scaling, Tabs in Titlebar
* 1.0 DPI scaling, Tabs NOT in Titlebar, always show tabs
* 1.0 DPI scaling, Tabs NOT in Titlebar, DON'T always show tabs
* 1.25 DPI scaling, Tabs NOT in Titlebar, always show tabs
* 1.25 DPI scaling, Tabs NOT in Titlebar, DON'T always show tabs
## Summary of the Pull Request
When we are maximized or fullscreened, check for the presence of the taskbar in auto-hide mode. If the Terminal finds the taskbar on any side of the monitor, adjust our window rect by just a little bit, so that the taskbar can still be revealed by the user mousing over that edge.
## References
## PR Checklist
* [x] Closes#1438
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Note to future code archeologists:
This doesn't seem to work for fullscreen on the primary display. However, testing a bunch of other apps with fullscreen modes and an auto-hiding taskbar has shown that _none_ of them reveal the taskbar from fullscreen mode. This includes Edge, Firefox, Chrome, Sublime Text, Powerpoint - none seemed to support this.
This does however work fine for maximized.
## Validation Steps Performed
I'm maximized and fullscreened the Terminal a lot in the last two days.
checkpointing this since it's so close. It works for everything but fullscreen on my primary, 125% display which has the taskbar on top, and autohides. Every other case works fine.
## Summary of the Pull Request
Add a `SizeChanged` handler to the titlebar content UI element. It's possible that this element's size will change after the dragbar's. When that happens, the drag bar won't send another `SizeChanged` event, because the dragbar's _size_ didn't change, only it's position.
## References
We originally duped this issue to #4166, but after #4829 fixed that issue, this one persisted. They're all related, and _look_ like dupes, but they weren't.
## PR Checklist
* [x] Closes#4288
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
I had a solid 100% repro that doesn't repro anymore.
I've maximized, restored, resized, and generally played with the window a bunch.
## Summary of the Pull Request
Pretty straightforward. When we get a `WM_DISPLAYCHANGE`, that means the
display's DPI changed. When that happens, resize the drag bar, so that
it'll reflect the new scaling.
Unblocks #4778Closes#4166
## Validation
Man I've changed the DPI of my displays so many times in the last 30
minutes. I dragged the window across a bunch of DPI boundaries too.
The Xaml input stack doesn't allow an application to suppress the "caret
browsing" dialog experience triggered when you press F7.
The official recommendation from the Xaml team is to catch F7 before we
hand it off.
This commit introduces a special F7 handler and an ad-hoc implementation of event bubbling.
Runtime classes implementing a custom IF7Listener interface are
considered during a modified focus parent walk to determine who can
handle F7 specifically.
If the recipient control handles F7, we suppress the message completely.
This event bubbler has some minor issues -- the search box will not be
able to receive F7 because its parent control implements the handler.
Since search is already mostly a text box, it doesn't _need_ special
caret browsing functionality as far as I can tell.
TermControl implements its OnF7Pressed handler by synthesizing a
keybindings event and an event to feed into Terminal Core directly.
It's not possible to create a synthetic KeyPressRoutedEvent; if it were,
I would have just popped one into the traditional input queue. :)
Fixes#638.
Generated by https://github.com/jsoref/spelling `f`; to maintain your repo, please consider `fchurn`
I generally try to ignore upstream bits. I've accidentally included some items from the `deps/` directory. I expect someone will give me a list of items to drop, I'm happy to drop whole files/directories, or to split the PR into multiple items (E.g. comments/locals/public).
Closes#4294
This fixes a crash caused by Narrator starting *before* terminal.
Fixes#2907.
For context,
```
// We must initialize the main thread as a single-threaded apartment before
// constructing any Xaml objects. Failing to do so will cause some issues
// in accessibility somewhere down the line when a UIAutomation object will
// be queried on the wrong thread at the wrong time.
// We used to initialize as STA only _after_ initializing the application
// host, which loaded the settings. The settings needed to be loaded in MTA
// because we were using the Windows.Storage APIs. Since we're no longer
// doing that, we can safely init as STA before any WinRT dispatches.
```
* Remove unneeded c_str() calls when converting an hstring to a wstring_view.
* Remove unneeded c_str() calls when constructing a FontInfo class with a wstring face name.
* Remove unneeded winrt::to_hstring calls when passing a wstring to a method that expects an hstring.
* Remove unneeded c_str() calls when passing an hstring to a method that already accepts hstrings without conversion.
* Remove unneeded c_str() and data() calls when explicitly constructing an hstring from a wstring.
## Summary of the Pull Request
Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495
## References
* Original issue: #607
* Original spec: #3495
## PR Checklist
* [x] Closes#607
* [x] I work here
* [x] Tests added/passed
* [ ] We should probably add some docs on these commands
* [x] The spec (#3495) needs to be merged first!
## Detailed Description of the Pull Request / Additional comments
🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now.
This PR adds support for three initial sub-commands to the `wt.exe` application:
* `new-tab`: Used to create a new tab.
* `split-pane`: Used to create a new split.
* `focus-tab`: Moves focus to another tab.
These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands
Important scenarios added:
* `wt -d .`: Open a new wt instance in the current working directory #878
* `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339
* `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756
## Validation Steps Performed
* Ran tests
* Played with it a bunch
When user resizes window, snap the size to align with the character grid
(like e.g. putty, mintty and most unix terminals). Properly resolves
arbitrary pane configuration (even with different font sizes and
padding) trying to align each pane as close as possible.
It also fixes terminal minimum size enforcement which was not quite well
handled, especially with multiple panes.
This PR does not however try to keep the terminals aligned at other user
actions (e.g. font change or pane split). That is to be tracked by some
other activity.
Snapping is resolved in the pane tree, recursively, so it (hopefully)
works for any possible layout.
Along the way I had to clean up some things as so to make the resulting
code not so cumbersome:
1. Pane.cpp: Replaced _firstPercent and _secondPercent with single
_desiredSplitPosition to reduce invariants - these had to be kept in
sync so their sum always gives 1 (and were not really a percent). The
desired part refers to fact that since panes are aligned, there is
usually some deviation from that ratio.
2. Pane.cpp: Fixed _GetMinSize() - it was improperly accounting for
split direction
3. TerminalControl: Made dedicated member for padding instead of
reading it from a control itself. This is because the winrt property
functions turned out to be slow and this algorithm needs to access it
many times. I also cached scrollbar width for the same reason.
4. AppHost: Moved window to client size resolution to virtual method,
where IslandWindow and NonClientIslandWindow have their own
implementations (as opposite to pointer casting).
One problem with current implementation is I had to make a long call
chain from the window that requests snapping to the (root) pane that
implements it: IslandWindow -> AppHost's callback -> App ->
TerminalPage -> Tab -> Pane. I don't know if this can be done better.
## Validation Steps Performed
Spam split pane buttons, randomly change font sizes with ctrl+mouse
wheel and drag the window back and forth.
Closes#2834Closes#2277
## Summary of the Pull Request
This latest MUX prerelease fixes the issue where the tab row wouldn't expand to fill the width of the window after shrinking the window size.
## PR Checklist
* [x] Closes#3300
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Thanks again @teaP for help fixing this
## Validation Steps Performed
Launched the terminal, played with it a bit
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Fixes the sides disappearing when entering full screen mode when the window is maximized.
However, now, a Vista-style frame briefly appears when entering/exiting full screen.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#3709
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] Requires documentation to be updated (no)
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
When the non-client island window is maximized and has the WS_OVERLAPPEDWINDOW style, SetWindowPos is "lying": the position ends up being offset compared to the one we gave it (found by debugging). So I changed it to use WS_POPUP like the client island window was already doing. But now it has the Vista frame that appears briefly when entering/exiting full screen like the client island window.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
Updates MUX to the latest pre-release version. This prerelease has a fix for a certain `E_LAYOUTCYCLE` bug in the TabView that was causing an untold number of crashes for us.
Thanks again @teaP!
## PR Checklist
* [x] Closes#3303
* [x] Closes#2277
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
This PR creates a Universal entrypoint for the Windows Terminal solution
in search of our goals to run everywhere, on all Windows platforms.
The Universal entrypoint is relatively straightforward and mostly just
invokes the App without any of the other islands and win32 boilerplate
required for the centennial route. The Universal project is also its own
packaging project all in one and will emit a relevant APPX.
A few things were required to make this work correctly:
* Vcxitems reuse of resources (and link instructions on all of them
for proper pkg layout)
* Move all Terminal project CRT usages to the app ones (and ensure
forwarders are only Nugetted to the Centennial package to not pollute
the Universal one)
* Fix/delay dependencies in `TerminalApp` that are not available in
the core platform (or don't have an appropriate existing platform
forwarder... do a loader snaps check)
* vcpkg needs updating for the Azure connection parser
* font fallbacks because Consolas isn't necessarily there
* fallbacks because there are environments without a window handle
Some of those happened in other small PRs in the past week or two. They
were relevant to this.
Note, this isn't *useful* as such yet. You can run the Terminal in this
context and even get some of the shells to work. But they don't do a
whole lot yet. Scoping which shells appear in the profiles list and only
offering those that contextually make sense is future work.
* Break everything out of App except the base initialization for XAML. AppLogic is the new home.
* deduplicate logics by always using the app one (since it has to be there to support universal launch).
* apparently that was too many cross-boundary calls and we can cache it because winrt objects are magic.
* Put UWP project into solution.
* tabs in titlebar needs disabling from uwp context as the non-client is way different. This adds a method to signal that to logic and apply the setting override.
* Change to use App CRT in preparation for universal.
* Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own.
* Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again.
* This fixes the build error.
* use the _apiset variant until proven otherwise to match the existing one.
* Merge branch 'master' into dev/miniksa/uwp3
* recorrect spacing in cppwinrt.build.pre.props
* Add multiple additional fonts to fallback to. Also, guard for invalid window handle on title update.
* Remove ARMs from solution.
* Share items resources between centennial and universal project.
* cleanup resources and split manifest for dev/release builds.
* Rev entire solution to latest Toolkit (6.0.0 stable release).
* shorten the items file using include patterns
* cleanup this filters file a bit.
* Fix C26445 by using string_view as value, not ref. Don't build Universal in Audit because we're not auditing app yet.
* some PR feedback. document losing the pointer. get rid of 16.3.9 workarounds. improve consistency of variable decl in applogic.h
* Make dev phone product ID not match prod phone ID. Fix universal package identity to match proposed license information.
It's apparently perfectly possible that DWM will just crash or close, and when
it does, `DwmExtendFrameIntoClientArea` will return a failure. If we
THROW_IF_FAILED that call, then we'll also crash when DWM does.
This converts that THROW_IF_FAILED to a LOG_IF_FAILED. When DWM comes back,
we'll hit this codepath again, and all will be right again in the world.
This commit cleans up and deduplicates all of the common build
preamble/postamble across exe, dll, lib and c++/winrt projects.
The following specific changes have been made:
* All projects now define their ConfigurationType
* All projects now set all their properties *before* including a common
build file (or any other build files)
* cppwinrt.pre and cppwinrt.post now delegate most of their
configuration to common.pre and common.post
* (becuase of the above,) all build options are conserved between
console and c++/winrt components, including specific warnings and
preprocessor definitions.
* More properties that are configurable per-project are now
conditioned so the common props don't override them.
* The exe, dll, exe.or.dll, and lib postincludes have been merged into
pre or post and switched based on condition as required
* Shared items (-shared, -common) are now explicitly vcxitems instead of
vcxproj files.
* The link line is now manipulated after Microsoft.Cpp sets it, so the
libraries we specify "win". All console things link first against
onecore_apiset.lib.
* Fix all compilation errors caused by build unification
* Move CascadiaPackage's resources into a separate item file
Fixes#922.
## Summary of the Pull Request
Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>.
The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor.
This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that.
## References
Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now.
A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs".
Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238.
## PR Checklist
* [x] Closes#531, #3411
* [x] I work here
* [n/a] Tests added/passed 😭
* [x] Requires documentation to be updated
## Validation Steps Performed
* Manually tested both the NonClientIslandWindow and the IslandWindow.
* Cherry-pick commit 8e56bfe
* Don't draw the tab strip when maximized
(cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613)
* Fix the vista window flash for the NCIW
(cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf)
* Some code cleanup for review
(cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32)
* A tad bit more notes and cleanup
* Update schema, docs
* Most of the PR comments
* I'm not sure this actually works, so I'm committing it to revert it and check
* Update some comments that were lost.
* Fix a build break?
* oh no
We take the standard window frame except that we remove the top part
(see `NonClientIslandWindow::_OnNcCalcSize`), then we put little 1 pixel
wide top border back in the client area using
`DwmExtendFrameIntoClientArea` and then we put the XAML island and the
drag bar on top.
Most of this PR is comments to explain how the code works and also
removing complex code that was needed to handle the weird cases when the
borders were custom.
I've also refactored a little bit the `NonClientIslandWindow` class.
* Fix DwmExtendFrameIntoClientArea values
* Fix WM_NCHITTEST handling
* Position the XAML island window correctly
* Fix weird colors in drag bar and hide old title bar buttons
* Fix the window's position when maximized
* Add support for dark theme on the frame
* DRY shared code between conhost and new terminal
* Fix drag bar and remove dead code
* Remove dead code and use cached DPI
* Refactor code
* Remove impossible TODO
* Use system metrics instead of hardcoding resize border height
* Use theme from app settings instead of system theme. Improve comments. Remove unused DWM frame on maximize.
* Fix initial position DPI handling bug and apply review changes
* Fix thick borders with DPI > 96
Closes#3064.
Closes#1307.
Closes#3136.
Closes#1897.
Closes#3222.
Closes#1859.
Due to a platform issue, elevated application packages occasionally fail
to find all of their dependencies. The real fix for this is going to
take a lot of time and probably a new build of Windows.
The fix we have here switches us to a non-"release" build of
Microsoft.UI.Xaml. The critical thing about their non-release builds is
that they prefer to embed their DLLs into the hosting package instead of
expressing a platform dependency.
This build of Microsoft.UI.Xaml was produced from the same commit as
the original and official build; the only difference is that it will
embed into our package.
Fixes#3275.
* Switch all of the UIA providers to WRL::RuntimeClass
Fixes#3209.
References #3051.
Co-authored-by: Carlos Zamora <cazamor@microsoft.com>
Co-authored-by: Dustin Howett <duhowett@microsoft.com>
This PR includes the code changes that enable users to set an initial position
(top left corner) and launch maximized. There are some corner cases:
1. Multiple monitors. The user should be able to set the initial position to
any monitors attached. For the monitors on the left side of the major monitor,
the initial position values are negative.
2. If the initial position is larger than the screen resolution and the window
is off-screen, the current solution is to check if the top left corner of the
window intersect with any monitors. If it is not, we set the initial position
to the top left corner of the nearest monitor.
3. If the user wants to launch maximized and provides an initial position, we
launch the maximized window on the monitor where the position is located.
# Testing
To test:
1. Check-out this branch and build on VS2019
2. Launch Terminal, and open Settings. Then close the terminal.
3. Add the following setting into Json settings file as part of "globals", just
after "initialRows":
"initialPosition": "1000, 1000",
"launchMode": "default"
My test data:
I have already tested with the following variables:
1. showTabsInTitlebar true or false
2. The initial position of the top left corner of the window
3. Whether to launch maximized
4. The DPI of the monitor
Test data combination:
Non-client island window (showTabsInTitlebar true)
1. Three monitors with the same DPI (100%), left, middle and right, with the
middle one as the primary, resolution: 1980 * 1200, 1920 * 1200, 1920 * 1080
launchMode: default
In-Screen test: (0, 0), (1000, 500), (2000, 300), (-1000, 400),
(-100, 200), (-2000, 100), (0, 1119)
out-of-screen:
(200, -200): initialize to (0, 0)
(200, 1500): initialize to (0, 0)
(2000, -200): initialize to (1920, 0)
(2500, 2000): initialize to (1920, 0)
(4000 100): initialize to (1920, 0)
(-1000, -100): initialize to (-1920, 0)
(-3000, 100): initialize to (-1920, 0)
(10000, -10000): initialize to (1920, 0)
(-10000, 10000): initialize to (-1920, 0)
(0, -10000): initialize to (0, 0)
(0, -1): initialize to (0, 0)
(0, 1200): initialize to (0, 0)
launch mode: maximize
(100, 100)
(-1000, 100): On the left monitor
(0, -2000): On the primary monitor
(10000, 10000): On the primary monitor
2. Left monitor 200% DPI, primary monitor 100% DPI
In screen: (-1900, 100), (-3000, 100), (-1000, 100)
our-of-screen: (-8000, 100): initialize at (-1920, 0)
launch Maximized: (-100, 100): launch maximized on the left monitor
correctly
3. Left monitor 100% DPI, primary monitor 200% DPI
In-screen: (-1900, 100), (300, 100), (-800, 100), (-200, 100)
out-of-screen: (-3000, 100): initialize at (-1920, 0)
launch maximized: (100, 100), (-1000, 100)
For client island window, the test data is the same as above.
Issues:
1. If we set the initial position on the monitor with a different DPI as the
primary monitor, and the window "lays" across two monitors, then the window
still renders as it is on the primary monitor. The size of the window is
correct.
Closes#1043
* We had to move to the final API:
* Items -> TabItems
* Items.VectorChanged -> TabItemsChanged
* TabClose -> TabCloseRequested
* TabViewItem.Icon -> TabViewItem.IconSource
* TabRowControl has been converted to a ContentPresenter, which
simplifies its logic a little bit.
* TerminalPage now differentiates MUX and WUX a little better
* Because of the change from Icon to IconSource in TabViewItem,
Utils::GetColoredIcon needed to be augmented to support MUX IconSources.
It was still necessary to use for WUX, so it's been templatized.
* I moved us from WUX SplitButton to MUX SplitButton and brought the
style in line with the one typically provided by TabView.
* Some of our local controls have had their backgrounds removed so
they're more amenable to being placed on other surfaces.
* I'm suppressing the TabView's padding.
* I removed a number of apparently dead methods from App.
* I've simplified the dragbar's sizing logic and eventing.
* The winmd harvester needed to be taught to not try to copy winmds for
framework packages.
* We now only initialize the terminal once we know the size
Closes#1896.
Closes#444.
Closes#857.
Closes#771.
Closes#760.
