Commit Graph

12 Commits

Author SHA1 Message Date
Mike Griese 442432ea15
Fixes the wapproj fast-up-to-date check (#11806)
I'm working on making the FastUpToDate check in Vs work for the Terminal project. This is one of a few PRs in this area.

FastUpToDate lets vs check quickly determine that it doesn't need to do anything for a given project. 

However, a few of our projects don't produce all the right artifacts, or check too many things, and this eventually causes the `wapproj` to rebuild, EVERY TIME YOU F5 in VS. 

This third PR deals with the Actual fast up to date check for the CascadiaPackage.wapproj. When #11804, #11805 and this PR are all merged, you should be able to just F5 the Terminal in VS, and then change NOTHING, and F5 it again, without doing a build at all. 




The wapproj `GetResolvedWinMD` target tries to get a winmd from every cppwinrt
executable we put in the package. But we DON'T produce a winmd. This makes the
FastUpToDate check fail every time, and leads to the whole wapproj build
running even if you're just f5'ing the package. EVEN AFTER A SUCCESSFUL BUILD.

Setting GenerateWindowsMetadata=false is enough to tell the build system that
we don't produce one, and get it off our backs.

### teams chat where we figured this out

[3:38 PM] Dustin Howett
however, that's not the only thing that "GetTargetPath" checks.

[3:38 PM] Dustin Howett
oh yeah more info: wapproj calls GetTargetPath on all projects it references

[3:38 PM] Dustin Howett
when it calls GTP on WindowsTerminal.vcxproj it is getting back a winmd (!)


[3:39 PM] Dustin Howett
here's the magic

[3:39 PM] Dustin Howett
![image](https://user-images.githubusercontent.com/18356694/142945542-74734836-20d8-4f50-bf3a-be4e1170ae13.png)


[3:39 PM] Dustin Howett
it checks if any Link items specify GenerateWindowsMetadata

![image](https://user-images.githubusercontent.com/18356694/142945593-fd232243-0175-4653-8c34-cdc364a16031.png)
2021-11-23 11:22:56 +00:00
Leonard Hecker fc85bdf314
Upgrade to Windows SDK 22000 (#11728)
Upgrades our SDK from 19041 (Windows 10 20H1) to 22000 (Windows 11 RTM).
The newer SDK is  more compatible with /Zc:preprocessor
and will allow us to use newer Windows 11 APIs directly.

## PR Checklist
* [x] I work here
* [x] Tests added/passed

## Validation Steps Performed
* Compiles ✔️
* Runs ✔️
2021-11-18 18:08:26 +00:00
Mike Griese cfe14e8711
Update to MUX 2.7 (#11240)
* this is the same thing as #10996, but with the fix that caused us to #11031  
* This includes https://github.com/microsoft/microsoft-ui-xaml/pull/3769, so we had to make some adjustments to how we handle tab colors. It works the same as before.
* Should enable #11231 to be started
* [x] Closes #10508
* [x] Closes #7133
* [x] Closes #8948
* [ ] I need to finish letting my 19H1 VM boot to make sure unpackaged still works
2021-09-20 22:08:55 +00:00
Mike Griese 74f11b8203
Enable Vintage Opacity (#11180)
## Summary of the Pull Request
![603-final](https://user-images.githubusercontent.com/18356694/132585665-afed3210-257a-4fee-9b43-4273a0f5cf69.gif)

Adds support for vintage style opacity, on Windows 11+. The API we're using for this exists since the time immemorial, but there's a bug in XAML Islands that prevents it from working right until Windows 11 (which we're working on backporting).

Replaces the `acrylicOpacity` setting with `opacity`, which is a uint between 0 and 100 (inclusive), default to 100.

`useAcrylic` now controls whether acrylic is used or not. Setting an opacity < 100 with `"useAcrylic": false` will use vintage style opacity.

Mouse wheeling adjusts opacity. Whether acrylic is used or not is dependent upon `useAcrylic`.

`opacity` will stealthily default to 50 if `useAcrylic:true` is set.

## PR Checklist
* [x] Closes #603
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/416

## Detailed Description of the Pull Request / Additional comments

Opacity was moved to AppearanceConfig. In the future, I have a mind to allow unfocused acrylic, so that'll be important then. 

## Validation Steps Performed
_just look at it_
2021-09-20 17:08:13 +00:00
Dustin L. Howett 3d7480e9b7
Upgrade to C++/WinRT 2.0.210825.3 (#11188)
This pull request moves us to Microsoft.Windows.CppWinRT 2.0.210825.3.

Notable improvements from 2.0.210309.3:
* Restored Windows 7 functionality
* C++20 ranges support
* `capture` now works with a raw pointer
* `hstring::starts_with` and `hstring::ends_with` (C++20)

Unit/Functional Tests:
Summary: Total=7728, Passed=7571, Failed=10, Blocked=0, Not Run=0, Skipped=147

Local Tests:
Summary: Total=163, Passed=158, Failed=5, Blocked=0, Not Run=0, Skipped=0

The above failures are (1) in UIA tests for conhost/WT (which do not work here) or
(2) in already known-broken local tests.
2021-09-10 21:33:13 +00:00
Dustin L. Howett f3cc4c0328
Revert "Upgrade to Microsoft.UI.Xaml 2.6.2 (or equivalent) (#10996)" (#11031)
The upgrade to 2.6 revealed #11003 and Microsoft/microsoft-ui-xaml#5435, and is impeding
progress on PGO.

This reverts commit cfdf03c24b.
Reverts microsoft/terminal#10996
2021-08-24 17:46:12 -05:00
Dustin L. Howett cfdf03c24b
Upgrade to Microsoft.UI.Xaml 2.6.2 (or equivalent) (#10996)
This commit moves us from MUX 2.5 to MUX 2.6. I have temporarily
disabled the new control styles in `TerminalApp\App.xaml` by setting
`ControlsResourcesVersion` to `Version1`. There is no significant expected
visual impact.

Closes #10508
2021-08-20 20:41:03 +00:00
Mike Griese 6e70c4ae07
Switch Connections to use `ValueSet`s to initialize them (#10184)
#### ⚠️ targets #10051 

## Summary of the Pull Request

This PR does one big, primary thing. It removes all the constructors from any TerminalConnections, and changes them to use an `Initialize` method that accepts a `ValueSet` of properties.

Why?

For the upcoming window/content process work, we'll need the content process to be able to initialize the connection _in the content process_. However, the window process will be the one that knows what type of connection to make. Enter `ConnectionInformation`. This class will let us specify the class name of the type we want to create, and a set of settings to use when initializing that connection.

**IMPORTANT**: As a part of this, the constructor for a connection must have 0 arguments. `RoActivateInstance` lets you just conjure a WinRT type just by class name, but that class must have a 0 arg ctor. Hence the need for `Initialize`, to actually pass the settings.

We're using a `ValueSet` here because it's basically a json blob, with more steps. In the future, when extension authors want to have custom connections, we can always deserialize the json into a `ValueSet`, pass it to their connection's `Initialize`, and let then get what they need out of it.

## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5

## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760298
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

`ConnectionInformation` was included as a part of this PR, to demonstrate how this will eventually be used. `ConnectionInformation` is not _currently_ used.

## Validation Steps Performed

It still builds and runs.
2021-07-20 15:02:17 +00:00
Dustin L. Howett e37fd5e546
Update Xaml Toolkit App Host to 6.1.3 (#10640)
This is required for some inbox compliance tasks regarding symbol availability.
2021-07-12 22:58:02 +00:00
Alexander Sklar 8c00dd7d55
Update WindowExe.manifest (#10499)
Closes #10480
2021-06-23 17:59:07 +00:00
Breece W 848e353b9c
Replicate winrt::make<> changes in ScratchIslandApp SampleAppLib (#10494)
Sample scratch app would not compile. It does if we apply #10335 to App.base.h in the scratch app.

Closes #10493
2021-06-23 03:21:07 +00:00
Mike Griese fe283fc28b Add a Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051

## Summary of the Pull Request

This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.

While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.

## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5

## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.

* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
  - It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.

Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).

## Validation Steps Performed

The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>

(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 12:56:47 -05:00