starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity
Files
1282d56a33bb15206fcb3a09d3bea0a33036f2cd
terminal/src/cascadia/UnitTests_SettingsModel/SettingsModel.UnitTests.vcxproj

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

116 lines
5.8 KiB
XML
Raw Normal View History

Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<?xml version="1.0" encoding="utf-8"?>
Make ToolsVersion more consistent in our project files (#13535) While working on another PR related to this I noticed that my VS generates `.vcxproj` files that are a bit different to the ones we have. This commit is a quick search & replace of all our project files to make (primarily) their `ToolsVersion` more in line with what VS does itself: No `ToolsVersion` for `.vcxproj`, `ToolsVersion="15.0"` for `.csproj` and `ToolsVersion="4.0"` for `.filters` files.
2022-07-27 00:31:42 +02:00
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<!-- A note about this project: We're building the test code dll from this
project, but it _MUST_ be run in conjunction with the TestHostApp project.
TestHostApp actually will build a TestHost executable and packaging bits
that we can use to run our tests. We need TestHostApp so that our
dependencies, like MUX, can be aggregated correctly, and resources properly
combined into a resources.pri file.
Minor grammar fix (#14614) `s/it's/its/` Note that I didn't touch the several errors in the doc and doc/spec directories, since those seem to be dated and signed email excerpts, and I don't want to violate authorial integrity. Let me know if you would like me to fix those as well. ## References p 57. Murray, L. (1824). English grammar. Philadelphia : E. T. Scott. I skimmed several hundred usages of the word "it's" in the code. This actually wasn't as tiresome as it sounds, since many of the code comments in this repo are entertaining and educational &mdash; the adjectives do not _necessarily_ apply in that order, but do _possibly_ apply in that order.
2023-01-09 11:25:03 -08:00
TestHostApp will manually copy the output of this project into its own
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
OutDir, so we can run the tests from there. -->
<PropertyGroup>
<ProjectGuid>{CA5CAD1A-9B68-456A-B13E-C8218070DC42}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
Make the Settings Model tests into proper CI tests (#16773) This pull request removes the need for the SettingsModel tests to run in a UAP harness and puts them into the standard CI rotation. This required some changes to `Run-Tests.ps1` to ensure that the right `te.exe` is selected for each test harness. It's a bit annoying, but for things that depend on a `resources.pri`, that file must be in the same directory as the EXE that is hosting the test. Not the DLL, mind you, the EXE. In our case, that's `TE.ProcessHost.exe` The bulk of the change is honestly namespace tidying. Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
2024-02-29 11:00:04 -06:00
<RootNamespace>SettingsModelUnitTests</RootNamespace>
<ProjectName>UnitTests_SettingsModel</ProjectName>
<TargetName>SettingsModel.Unit.Tests</TargetName>
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<ConfigurationType>DynamicLibrary</ConfigurationType>
Remove all our path antics; force native projects to bin/, obj/ (#8062) 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.
2020-10-27 15:00:41 -07:00
<OpenConsoleCppWinRTProject>true</OpenConsoleCppWinRTProject>
Terminal would benefit from having a single canonical version number for each of its NuGet dependencies (#12707) These changes are purely a refactoring of the build files. There should be no difference to the compiled result or runtime behavior. Currently there are packages.config files in lots of directories, with those same projects referencing props/targets from packages/ with a version string in the path. This is frustrating because version changes or new dependencies require updating lots and lots of build files identically. There is also the possibility of error where locations are missed. With these changes there is a single canonical nuget configuration that takes effect for all of OpenConsole.sln. Updating version numbers should be limited to a single set of global files. The changes were done incrementally but the result is basically that dep\nuget\packages.config serves as the global NuGet dependency list. A pair of common build files (common.nugetversions.props and common.nugetversions.targets) were added to contain the various imports and error checks. There is also a special build target to ensure that the restore happens before builds even though a given directory doesn't have a packages.config for Visual Studio to observe. These new *.nugetversions.* files are imported in pretty much every vcxproj/csproj in the solution in the appropriate place to satisfy the need for packages. There are opt-in configuration values (e.g. `TerminalCppWinrt=true`) that must be set to opt into a given dependency. Adding a new dependency is just a matter of adding a new opt-in value. The ordering of include does matter, which was a difficult challenge to realize and address. There was also a preexisting issue in 3 test projects where cppwinrt.props was included but not cppwinrt.targets. By consolidating things globally that "error" was fixed, but broke the build in a way that was very confusing. Those projects don't need the cppwinrt targets so they were opted out of the cppwinrt build files entirely to fix the breaks and get back to previous behavior. There are two notable exceptions to this canonical versioning. The first is that there are dueling XAML 2.7 dependencies. I avoided that by leaving those as per-project package.config entries. The second is that any projects outside of the .sln (such as the Island samples) were not touched. ## Validation Steps Performed The primary validation is that the solution builds without errors. That is what I'm seeing (x64|Debug). I also ran `git clean -fdx` from the root of the repo to wipe it to clean and then opened the solution and was able to build successfully. The project F5 deploys and looks fine to me with just a cursory glance. The tests also largely pass (7418 pass, 188 fail, 14 other) which is as good or better than the baseline I established from a clean clone. Closes #12708
2022-03-28 11:31:36 -07:00
<!-- TerminalCppWinrt is not set intentionally -->
Consolidate our MSIX distribution back down to one package (#15031) We ship a separate package to Windows 10, which contains a copy of XAML embedded in it, because of a bug in activating classes from framework packages while we're elevated. We did this to avoid wasting disk space on Windows 11 installs (which is critical given that we're preinstalled in the Windows image.) The fix for this issue was released in a servicing update in April 2022. Thanks to KB5011831, we no longer need this workaround! And finally, this means that we no longer need to depend on a copy of "pre-release" XAML. We only did that because it would copy all of its assets into our package. Introduced in #12560 Closes #14106 Closes (discussion) #14981 Reverts #14660
2023-03-24 08:31:17 -05:00
<TerminalMUX>true</TerminalMUX>
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
</PropertyGroup>
<Import Project="$(SolutionDir)\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
Terminal would benefit from having a single canonical version number for each of its NuGet dependencies (#12707) These changes are purely a refactoring of the build files. There should be no difference to the compiled result or runtime behavior. Currently there are packages.config files in lots of directories, with those same projects referencing props/targets from packages/ with a version string in the path. This is frustrating because version changes or new dependencies require updating lots and lots of build files identically. There is also the possibility of error where locations are missed. With these changes there is a single canonical nuget configuration that takes effect for all of OpenConsole.sln. Updating version numbers should be limited to a single set of global files. The changes were done incrementally but the result is basically that dep\nuget\packages.config serves as the global NuGet dependency list. A pair of common build files (common.nugetversions.props and common.nugetversions.targets) were added to contain the various imports and error checks. There is also a special build target to ensure that the restore happens before builds even though a given directory doesn't have a packages.config for Visual Studio to observe. These new *.nugetversions.* files are imported in pretty much every vcxproj/csproj in the solution in the appropriate place to satisfy the need for packages. There are opt-in configuration values (e.g. `TerminalCppWinrt=true`) that must be set to opt into a given dependency. Adding a new dependency is just a matter of adding a new opt-in value. The ordering of include does matter, which was a difficult challenge to realize and address. There was also a preexisting issue in 3 test projects where cppwinrt.props was included but not cppwinrt.targets. By consolidating things globally that "error" was fixed, but broke the build in a way that was very confusing. Those projects don't need the cppwinrt targets so they were opted out of the cppwinrt build files entirely to fix the breaks and get back to previous behavior. There are two notable exceptions to this canonical versioning. The first is that there are dueling XAML 2.7 dependencies. I avoided that by leaving those as per-project package.config entries. The second is that any projects outside of the .sln (such as the Island samples) were not touched. ## Validation Steps Performed The primary validation is that the solution builds without errors. That is what I'm seeing (x64|Debug). I also ran `git clean -fdx` from the root of the repo to wipe it to clean and then opened the solution and was able to build successfully. The project F5 deploys and looks fine to me with just a cursory glance. The tests also largely pass (7418 pass, 188 fail, 14 other) which is as good or better than the baseline I established from a clean clone. Closes #12708
2022-03-28 11:31:36 -07:00
<Import Project="$(OpenConsoleDir)src\common.nugetversions.props" />
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<Import Project="$(OpenConsoleDir)\src\cppwinrt.build.pre.props" />
<!-- ========================= Headers ======================== -->
<ItemGroup>
<ClInclude Include="pch.h" />
<ClInclude Include="JsonTestClass.h" />
</ItemGroup>
<!-- ========================= Cpp Files ======================== -->
<ItemGroup>
<ClCompile Include="ProfileTests.cpp" />
<ClCompile Include="ColorSchemeTests.cpp" />
<ClCompile Include="KeyBindingsTests.cpp" />
<ClCompile Include="CommandTests.cpp" />
<ClCompile Include="DeserializationTests.cpp" />
Fix a crash on startup with a `folder` entry without `entries` (#14629) `_Entries` was getting default constructed to `nullptr`. We should be careful about that. Adds a test too, and fixes a regression in the local tests introduced in #13763. Closes #14557
2023-01-19 13:12:40 -06:00
<ClCompile Include="NewTabMenuTests.cpp" />
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
<ClCompile Include="SerializationTests.cpp" />
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-15 16:15:25 -07:00
<ClCompile Include="TerminalSettingsTests.cpp" />
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
<ClCompile Include="ThemeTests.cpp" />
Rewrite media resource handling (relative path icons, web URLs) (#19143) This pull request broadly rewrites how we handle all media resources in the Terminal settings model. ## What is a media resource? A media resource is any JSON property that refers to a file on disk, including: - `icon` on profile - `backgroundImage` on profile (appearance) - `pixelShaderPath` and `pixelShaderImagePath` on profile (appearance) - `icon` on command and the new tab menu entries The last two bullet points were newly discovered during the course of this work. ## Description of Changes In every place the settings model used to store a string for a media path, it now stores an `IMediaResource`. A media resource must be _resolved_ before it's used. When resolved, it can report whether it is `Ok` (found, valid) and what the final normalized path was. This allows the settings model to apply some new behaviors. One of those new behaviors is resolving media paths _relative to the JSON file that referred to them._ This means fragments and user settings can now contain _local_ images, pixel shaders and more and refer to them by filename. Relative path support requires us to track the path from which every media resource "container" was read[^2]. For "big" objects like Profile, we track it directly in the object and for each layer. This means that fragments **updating** a profile pass their relative base path into the mix. For some of the entries such as those in `newTabMenu`, we just wing it (#19191). For everything that is recursively owned by a parent that has a path (say each Command inside an ActionMap), we pass it in from the parent during media resolution. During resolution, we now track _exactly which layer_ an icon, background image, or pixel shader path came from and read the "base path" from only that layer. The base path is not inherited. Another new behavior is in the handling of web and other URLs. Canonical and a few other WSL distributors had to resort to web URLs for icons because we did not support loading them from the package. Julia tried to use `ms-appx://JuliaPackageNameHere/path/to/icon` for the same reason. Neither was intended, and of the two the second _should_ have worked but never could[^1]. For both `http(s?)` URLs and `ms-appx://` URLs which specify a package name, we now strip everything except the filename. As an example... If my fragment specifies `https://example.net/assets/foo.ico`, and my fragment was loaded from `C:\Fragments`, Terminal will look *only* at `C:\Fragments\foo.ico`. This works today for Julia (they put their icon in the fragment folder hoping that one day we would support this.) It will require some work from existing WSL distributors. I'm told that this is similar to how XML schema documents work. Now, icons are special. They support _Emoji_ and _Segoe Icons_. This PR adds an early pass to avoid resolving anything that looks like an emoji. This PR intentionally expands the heuristic definition of an emoji. It used to only cover 1-2 code unit emoji, which prevented the use of any emoji more complicated than "man in business suite levitating." An icon path will now be considered an emoji or symbol icon if it is composed of a single grapheme cluster (as measured by ICU.) This is not perfect, as it errs on the side of allowing too many things... but each of those things is technically a single grapheme cluster and is a perfectly legal FontIcon ;) Profile icons are _even more special_ than icons. They have an additional fallback behavior which we had to preserve. When a profile icon fails validation, or is expressly set to `null`, we fall back to the EXE specified in the command line. Because we do this fallback during resolution, _and the icon may be inherited by any higher profile,_ we can only resolve it against the commandline at the same level as the failed or nulled icon. Therefore, if you specify `icon: null` in your `defaults` profile, it will only ever resolve to `cmd.exe` for any profile that inherits it (unless you change `defaults.commandline`). This change expands support for the magic keywords `desktopWallpaper` and `none` to all media paths (yes, even `pixelShaderPath`... but also, `pixelShaderImagePath`!) It also expands support for _environment variables_ to all of those places. Yes, we had like forty different handlers for different types of string path. They are now uniform. ## Resource Validation Media resources which are not found are "rejected". If a rejected resource lives in _user_ settings, we will generate a warning and display it. In the future, we could detect this in the Settings UI and display a warning inline. ## Surprises I learned that `Windows.Foundation.Uri` parses file paths into `file://` URIs, but does not offer you a way to get the original file path back out. If you pass `C:\hello world`, _`Uri.Path`_ will return `/C:/hello%20world`. I kid you not. As a workaround, we bail out of URL handling if the `:` is too close to the start (indicating an absolute file path). ## Testing I added a narow test hook in the media resource resolver, which is removed completely by link-time code generation. It is a real joy. The test cases are all new and hopefully comprehensive. Closes #19075 Closes #16295 Closes #10359 (except it doesn't support fonts) Supersedes #16949 somewhat (`WT_SETTINGS_DIR`) Refs #18679 Refs #19215 (future work) Refs #19201 (future work) Refs #19191 (future work) [^1]: Handling a `ms-appx` path requires us to _add their package to our dependency graph_ for the entire duration during which the resource will be used. For us, that could be any time (like opening the command palette for the first time!) [^2]: We don't bother tracking where the defaults came from, because we control everything about them.
2025-08-05 15:47:50 -05:00
<ClCompile Include="MediaResourceTests.cpp" />
Add support for "workspaces" based on window names (redux) (#20314) This adds a new feature to the Windows Terminal: "Workspaces" Workspaces are very shamelessly inspired by Edge workspaces of the same name. The core idea is that when users name a window and they close that window, we will persist that Windows layout and buffers, seperately from the rest of window restoration. So a user can open a named window, open some profiles, some panes, do some stuff in it, then close it, and we will keep that state around for the next time the user opens that window name. Unnamed windows still behave the same. If you close an unnamed window, and it's not the last window, then we won't persist the state of it. To facilitate restoring named windows, we add a `openWorkspace` action. This allows us to persist the open workspace action in the window layout restoration path. So when we deserialize the list of tab layouts, and open workspace action will tell us, hey, go retrieve this known workspace from the state.json, instead of trying to serialize the window state in two places. As demoed in the video, we add a flyout to list the windows that the user has open, and the named workspaces that they have saved. This allows users to quickly reopen previously closed workspaces, as well as quickly rename a window, thereby adding it to the list of saved workspaces. This button can also be hidden using the theme settings. Closes #17084 (this is a reboot of #20162, but with the event from #20311)
2026-06-16 16:59:17 -05:00
<ClCompile Include="ApplicationStateTests.cpp" />
Remove TerminalSettings from the TerminalSettingsModel project (#19262) The idea with IControlSettings (and friends) was always that a consumer of the terminal control could implement it in whatever way they pleased. Windows Terminal (the application) was intended to be only one consumer. It has a whole JSON settings model. Nobody wants to think about JSON at the Terminal Control level. We could have an "adapter" in TerminalApp, which spoke Terminal JSON Settings on one side and Terminal Control on the other side. That worked until we added the settings editor. The settings editor needed to display a control, and that control's settings needed to be based on the JSON settings. Oops. We took the expedient route of moving the adapter into TerminalSettingsModel itself, and poking a bunch of holes in it so that TerminalApp and TerminalSettingsEditor could tweak it as needed. Later, we doubled down on the control settings interface by having every Terminal Control _make its own ControlSettings_ when we were going to do the multi-process model. This reduced the number of IPC round trips for every settings query to 0. Later we built color scheme previewing on top of that--adding structs to carry color schemes and stuff which was already in the Appearance config. Sheesh. Layers and layers and layers. This pull request moves it back into its own library and strips it from the surface of TerminalSettingsModel. It also deletes `ControlSettings` and `struct CoreScheme`. That library is called `TerminalSettingsAppAdapterLib`, and it contains a hidden WinRT _implements_ type rather than a full-fledged activatable `runtimeclass`. It also implements one-level inheritance on its own rather than using IInheritable. It adheres to the following principles: - The control will never modify its settings in a way that is visible to the control's consumer; therefore, none of the properties have setters - The settings should never contain things of interest only to the Application that the Application uses to communicate data _back to itself_ (see `ProfileName`, removed in 68b723c and `KeyBindings`, removed in fa09141). This generalizes to "we should never store stuff in an unrelated object passed between layers solely for the purpose of getting it back". I made a few changes to the settings interface, including introducing a new `ICoreScheme` interface that _only_ contains color scheme info. This is designed to support the Preview/Set color scheme actions, which no longer work by _app backing up the scheme and restoring it later._ All of that machinery lives inside TermControl/ControlCore now. `ICoreScheme` no longer supports `GetColorAtIndex`; you must read all 16 colors at the same time. I am not sorry. Every consumer did that already, so now we have 15 fewer COM calls for every color scheme. The new TerminalSettings is mostly consumed via `com_ptr<TerminalSettings>`, so a bunch of `.` (projected) accesses had to turn into `->` (com_ptr dereferencing) accesses. I also realized, in the course of this work, that the old TerminalSettings contained a partial hand-written reimplementation of _every setting_ in `ControlProperties`. Every contributor had to add every new setting to both places--why? I can't figure it out. I'm using ControlProperties comprehensively now. I propagated any setting whose default value was different from that in ControlProperties back to ControlProperties. This is part X in a series of pull requests that will remove all mention of Microsoft.Terminal.Control and Microsoft.Terminal.Core from the settings model. Once that is done, the settings model can consume _only_ the base WinRT types and build very early and test more easily. Previewing is fun. I introduced a new place to stash an entire color table on ControlCore, which we use to save the "active" colors while we temporarily overwrite them. SetColorScheme is _also_ fun. We now have a slot for overriding only the focused color scheme on ControlCore. It's fine. It's clearer than "back up the focused appearance, overwrite the focused appearance, create a child of the user's settings and apply the color scheme to it, etc.". There is a bug/design choice in color scheme overriding, which may or may not matter: overlaying a color scheme on a terminal with an unfocused appearance which _does not_ have its own color scheme will result in the previously-deleted overridden focused color scheme peeking through when the terminal is not focused. I also got rid of our only in-product use of `Terminal::CreateFromSettings` which required us to set `InitialRows` and `InitialCols` on the incoming settings object (see core tenet 2). Refs #19261 Refs #19314 Refs #19254
2025-09-03 14:01:36 -05:00
<ClCompile Include="../TerminalSettingsAppAdapterLib/TerminalSettings.cpp" />
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<ClCompile Include="pch.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
</ItemGroup>
<!-- ========================= Project References ======================== -->
<ItemGroup>
<ProjectReference Include="$(OpenConsoleDir)\src\cascadia\TerminalSettingsModel\Microsoft.Terminal.Settings.ModelLib.vcxproj" />
<ProjectReference Include="$(OpenConsoleDir)\src\types\lib\types.vcxproj" />
Implement UI for choosing default terminal inside Settings page (#9907) Implement dropdown menu for choosing a default terminal application from inside the Windows Terminal Settings UI ## PR Checklist * [x] Closes #9463 * [x] I work here. * [x] Manual tests passed * [x] https://github.com/MicrosoftDocs/terminal/issues/314 (and cross reference #9462) ## Detailed Description of the Pull Request / Additional comments - Adds dropdown menu and a template card for displaying the available default applications (using the same lookup code as the console property sheet `console.dll`) - Adds model to TSM for adapting the data for display and binding on XAML - Lookup occurs on every page reload. Persistence only happens on Save Changes. - Manifest changed for Terminal to add capability to opt-out of registry redirection so we can edit this setting ## Validation Steps Performed - [x] Flipped the menu and pressed Save Changes and launched cmd from run box... it moved between the two. - [x] Flipped system theme from light to dark and ensured secondary color looked good - [x] Flipped the status with a different mechanism (conhost propsheet) and then reopened settings page and confirmed it loaded the updated status
2021-04-28 03:43:30 -07:00
<ProjectReference Include="$(OpenConsoleDir)src\propslib\propslib.vcxproj" />
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<!-- If you don't reference these projects here, the
_ConsoleGenerateAdditionalWinmdManifests step won't gather the winmd's -->
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **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.
2021-03-17 15:47:24 -05:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalControl\dll\TerminalControl.vcxproj" />
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalConnection\TerminalConnection.vcxproj" />
Move LibraryResourceLoader to PCH (#19184) It is foundational enough that everyone should have access by now.
2025-12-02 14:33:02 -06:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\WinRTUtils\WinRTUtils.vcxproj">
<Project>{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
</ItemGroup>
<!-- ========================= Globals ======================== -->
<!-- ====================== Compiler & Linker Flags ===================== -->
<ItemDefinitionGroup>
<ClCompile>
Move our big OSS dependencies to vcpkg (#15855) This pull request removes the following vendored open source, in favor of getting it from vcpkg: - CLI11 2.4 - jsoncpp 1.9 - fmt 7.1.3 - gsl 3.1 (not vendored, but submoduled--arguably worse!) Now that Visual Studio 2022 includes a built-in workload for vcpkg, the onboarding process is much smoother. Terminal should only require the vcpkg workload. I've added some build rules that detect vcpkg via VS and via the user's environment before falling back to a location in the source tree. The CI pipeline will fall back to installing and bootstrapping vcpkg in dep/vcpkg if necessary. Some OSS has not been (and will not be) migrated: - wyhash: ours is included directly in til/hash - pcg_random: we have a stripped down copy compared to vcpkg - stb_rect: vcpkg only ships *all of STB*; ours is a stripped down copy - chromium numerics: vcpkg does not ship Chromium, especially not this tiny fraction of Chromium - dynamic_bitset and libpopcnt: removing in #17510 - interval_tree: no vcpkg equivalent To support the needs of the inbox Windows build, I've split up our vcpkg manifest into dependencies for all projects and dependencies just for Terminal. To support this, we now offer a `terminal` feature. The vcpkg rules in `common.build.pre.props` are set up to turn it on, whereas the build rules we eventually write for the OS will not be. Most of the work is concentrated in `common.build.pre.props`.
2024-07-19 11:29:37 -07:00
<AdditionalIncludeDirectories>..;$(OpenConsoleDir)\dep;$(OpenConsoleDir)src\inc;$(OpenConsoleDir)src\inc\test;$(WinRT_IncludePath)\..\cppwinrt\winrt;"$(OpenConsoleDir)\src\cascadia\TerminalSettingsModel\Generated Files";%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
<PrecompiledHeaderFile>pch.h</PrecompiledHeaderFile>
<!-- Manually disable unreachable code warning, because jconcpp has a ton of that. -->
<DisableSpecificWarnings>4702;%(DisableSpecificWarnings)</DisableSpecificWarnings>
</ClCompile>
<Link>
Use `.rc` files in TSM instead of string literals (#16844) More prerequisite work for Action IDs - turns out if we add the action IDs to the actions defined in `defaults.json` the string ends up being too large and the compiler complains about it. Use a `.rc` file for `defaults.json` instead and also for `enableColorSelection.json` + `userDefaults.json`.
2024-03-14 13:50:07 -07:00
<AdditionalDependencies>onecoreuap.lib;%(AdditionalDependencies);$(IntDir)\..\Microsoft.Terminal.Settings.Model.lib\Microsoft.Terminal.Settings.Model.res</AdditionalDependencies>
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-04 21:50:13 -07:00
<!--
SettingsModelLib contains a DllMain that we need to force the use of.
If you don't have this, then you'll see an error like
"(init.obj) : error LNK2005: DllMain already defined in MSVCRTD.lib(dll_dllmain_stub.obj)"
-->
build: ship a Win11 build of Terminal that's <=half the size (#12560) Four (4) squashed changes, with messages preserved. ## release: move symbol publication into its own phase Right now, symbol publication happens every time we produce a final bundle. In the future, we may be producing multiple bundles from the same pipeline run, and we need to make sure we only do *one* symbol publication to MSDL. When we do that, it will be advantageous for us to have just one phase that source-indexes and publishes all of the symbols. ## Remove Terminal's built-in copy of the VC Runtime This removes the trick we pulled in #5661 and saves us ~550kb per arch. Some of our dependencies still depend on the "app" versions of the runtime libraries, so we are going to continue shipping the forwarders in our package. Build rules have been updated to remove the non-Desktop VCLibs dependency to slim down our package graph. This is not a problem on Windows 11 -- it looks like it's shipped inbox. **BREAKING CHANGE**: When launched unpackaged, Terminal now requires the vcruntime redist to be installed. ## Prepare for toggling XAML between 2.7.0 and -prerelease on Win11 common.openconsole.props is a pretty good place to stash the XAML version since it is included in every project (including the WAP project (unlike the C++ build props!)). I've gone ahead and added a "double dependency" on multiple XAML versions. We'll toggle them with a build flag. ## Run the release pipeline twice, for Win10 and Win11, at the same time This required some changes in how we download artifacts to make sure that we could control which version of Windows we were processing in any individual step. We're also going to patch the package manifest on the Windows 11 version so the store targets it more specifically. On top of the prior three steps, this lets us ship a Windows 11 package that costs only ~15MB on disk. The Windows 10 version, for comparison, is about 40.
2022-02-24 18:09:28 -06:00
<AdditionalOptions Condition="'$(Platform)'=='Win32'">%(AdditionalOptions) /INCLUDE:_DllMain@12</AdditionalOptions>
<AdditionalOptions Condition="'$(Platform)'!='Win32'">%(AdditionalOptions) /INCLUDE:DllMain</AdditionalOptions>
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
</Link>
</ItemDefinitionGroup>
<PropertyGroup>
<GenerateManifest>true</GenerateManifest>
<EmbedManifest>true</EmbedManifest>
</PropertyGroup>
<!-- Careful reordering these. Some default props (contained in these files) are order sensitive. -->
<Import Project="$(OpenConsoleDir)src\common.build.post.props" />
<Import Project="$(OpenConsoleDir)src\common.build.tests.props" />
Terminal would benefit from having a single canonical version number for each of its NuGet dependencies (#12707) These changes are purely a refactoring of the build files. There should be no difference to the compiled result or runtime behavior. Currently there are packages.config files in lots of directories, with those same projects referencing props/targets from packages/ with a version string in the path. This is frustrating because version changes or new dependencies require updating lots and lots of build files identically. There is also the possibility of error where locations are missed. With these changes there is a single canonical nuget configuration that takes effect for all of OpenConsole.sln. Updating version numbers should be limited to a single set of global files. The changes were done incrementally but the result is basically that dep\nuget\packages.config serves as the global NuGet dependency list. A pair of common build files (common.nugetversions.props and common.nugetversions.targets) were added to contain the various imports and error checks. There is also a special build target to ensure that the restore happens before builds even though a given directory doesn't have a packages.config for Visual Studio to observe. These new *.nugetversions.* files are imported in pretty much every vcxproj/csproj in the solution in the appropriate place to satisfy the need for packages. There are opt-in configuration values (e.g. `TerminalCppWinrt=true`) that must be set to opt into a given dependency. Adding a new dependency is just a matter of adding a new opt-in value. The ordering of include does matter, which was a difficult challenge to realize and address. There was also a preexisting issue in 3 test projects where cppwinrt.props was included but not cppwinrt.targets. By consolidating things globally that "error" was fixed, but broke the build in a way that was very confusing. Those projects don't need the cppwinrt targets so they were opted out of the cppwinrt build files entirely to fix the breaks and get back to previous behavior. There are two notable exceptions to this canonical versioning. The first is that there are dueling XAML 2.7 dependencies. I avoided that by leaving those as per-project package.config entries. The second is that any projects outside of the .sln (such as the Island samples) were not touched. ## Validation Steps Performed The primary validation is that the solution builds without errors. That is what I'm seeing (x64|Debug). I also ran `git clean -fdx` from the root of the repo to wipe it to clean and then opened the solution and was able to build successfully. The project F5 deploys and looks fine to me with just a cursory glance. The tests also largely pass (7418 pass, 188 fail, 14 other) which is as good or better than the baseline I established from a clean clone. Closes #12708
2022-03-28 11:31:36 -07:00
<Import Project="$(OpenConsoleDir)src\common.nugetversions.targets" />
Make the Settings Model tests into proper CI tests (#16773) This pull request removes the need for the SettingsModel tests to run in a UAP harness and puts them into the standard CI rotation. This required some changes to `Run-Tests.ps1` to ensure that the right `te.exe` is selected for each test harness. It's a bit annoying, but for things that depend on a `resources.pri`, that file must be in the same directory as the EXE that is hosting the test. Not the DLL, mind you, the EXE. In our case, that's `TE.ProcessHost.exe` The bulk of the change is honestly namespace tidying. Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
2024-02-29 11:00:04 -06:00
<ItemGroup>
<ProjectPriFiles Include="$(TargetDir)\Microsoft.Terminal.Settings.Model.pri" />
<OutputPriFiles Include="$(TargetDir)\resources.pri" />
</ItemGroup>
<Target Name="AfterBuild" Inputs="@(ProjectPriFiles)" Outputs="@(OutputPriFiles)">
<Copy SourceFiles="@(ProjectPriFiles)"
DestinationFiles="@(OutputPriFiles)"
UseHardLinksIfPossible="true"
SkipUnchangedFiles="true" />
</Target>
Introduce TerminalSettingsModel project (#7667) 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
2020-10-06 09:56:59 -07:00
</Project>
Reference in New Issue Copy Permalink