maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/TerminalSettingsModel/Microsoft.Terminal.Settings.ModelLib.vcxproj.filters

127 lines
4.7 KiB
Plaintext
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 18:56:59 +02:00
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Natvis Include="$(SolutionDir)tools\ConsoleTypes.natvis" />
</ItemGroup>
<ItemGroup>
<PRIResource Include="Resources\en-US\Resources.resw" />
</ItemGroup>
<ItemGroup>
<ClCompile Include="pch.cpp" />
<ClCompile Include="$(GeneratedFilesDir)module.g.cpp" />
<ClCompile Include="AzureCloudShellGenerator.cpp">
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="PowershellCoreProfileGenerator.cpp">
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="WslDistroGenerator.cpp">
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="CascadiaSettings.cpp" />
<ClCompile Include="CascadiaSettingsSerialization.cpp" />
<ClCompile Include="GlobalAppSettings.cpp" />
<ClCompile Include="KeyChordSerialization.cpp" />
<ClCompile Include="Profile.cpp" />
<ClCompile Include="ColorScheme.cpp" />
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
<ClCompile Include="DynamicProfileUtils.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 18:56:59 +02:00
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="$(OpenConsoleDir)\dep\jsoncpp\jsoncpp.cpp">
<Filter>json</Filter>
</ClCompile>
<ClCompile Include="init.cpp" />
Move IconSourceConverter from TerminalApp to TSM The Settings UI will need to take a dependency on IconSourceConverter.
2020-11-05 01:55:16 +01:00
<ClCompile Include="IconPathConverter.cpp" />
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 12:43:30 +02:00
<ClCompile Include="DefaultTerminal.cpp" />
Enable /Zc:preprocessor (#10593) This commit is a preparation for upcoming changes to KeyChordSerialization for #7539 and #10203. In order to support variadic macros, /Zc:preprocessor was enabled, which required changing unrelated parts of the project. ## PR Checklist * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Project still compiles ✔️
2021-07-14 01:00:11 +02:00
<ClCompile Include="FileUtils.cpp" />
Show only latest VS, VC prompts by default (#11326) ## Summary of the Pull Request Similar to `vswhere -latest`, show only the latest Visual Studio command prompts / developer PowerShell. This was tested by deleting the local package state and testing against fresh state with both VS2019 and VS2022 Preview installed, and indeed VS2022 Preview (both cmd and powershell) show. The other profiles were generated but hidden by default. ## References Modification of PR #7774 ## PR Checklist * [x] Closes #11307 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] 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. * [x] 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 ## Detailed Description of the Pull Request / Additional comments The sort algorithm is the same basic algorithm I used in https://github.com/microsoft/vswhere. It sorts first by installation version with a secondary sort based on the install date in case the installation versions are the same. ## Validation Steps Performed With both VS2019 and VS2022 Preview installed, I made sure the initial state was expected, and tried different combinations of hiding and unhiding generated entries, and restarted Terminal to make sure my settings "stuck".
2021-09-30 00:03:05 +02:00
<ClCompile Include="VisualStudioGenerator.cpp">
Add profile generators for Visual Studio (#7774) This commit adds dynamic profile generators for Visual Studio Developer Command Prompt (VS2017+) and Visual Studio Developer PowerShell (VS2019.2+) Tested manually by deploying locally. My local environment has four instances of VS installed, one VS2017 and multiple channels of VS2019. We're wrapping the COM Visual Studio Setup Configuration API to query for VS instances and retrieve the relevant properties. Two different namespaces are used so the end-user can turn off one or the other. For instance, end user may prefer to always use Developer PowerShell. ## Validation Steps Performed 1. Build locally using Visual Studio 2019 2. Deploy CascadiaPackage 3. Verify entries exist in profiles menu 4. Verify entries exist in settings.json 5. Open each profile 6. Validate start-in directory 7. Validate environment variables are as expected 8. Uninstall Windows Terminal - Dev package 9. Repeat. Closes #3821
2021-09-16 00:20:06 +02:00
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="VsDevCmdGenerator.cpp">
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="VsDevShellGenerator.cpp">
<Filter>profileGeneration</Filter>
</ClCompile>
<ClCompile Include="VsSetupConfiguration.cpp">
<Filter>profileGeneration</Filter>
</ClCompile>
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 18:56:59 +02:00
</ItemGroup>
<ItemGroup>
<ClInclude Include="pch.h" />
<ClInclude Include="AzureCloudShellGenerator.h">
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="IDynamicProfileGenerator.h">
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="PowershellCoreProfileGenerator.h">
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="WslDistroGenerator.h">
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="CascadiaSettings.h" />
<ClInclude Include="GlobalAppSettings.h" />
<ClInclude Include="TerminalSettingsSerializationHelpers.h" />
<ClInclude Include="KeyChordSerialization.h" />
<ClInclude Include="Profile.h" />
<ClInclude Include="SettingsTypes.h" />
<ClInclude Include="TerminalWarnings.h" />
<ClInclude Include="ColorScheme.h" />
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
<ClInclude Include="DynamicProfileUtils.h">
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 18:56:59 +02:00
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="JsonUtils.h">
<Filter>json</Filter>
</ClInclude>
Move IconSourceConverter from TerminalApp to TSM The Settings UI will need to take a dependency on IconSourceConverter.
2020-11-05 01:55:16 +01:00
<ClInclude Include="IInheritable.h" />
<ClInclude Include="IconPathConverter.h" />
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 12:43:30 +02:00
<ClInclude Include="DefaultTerminal.h" />
Enable /Zc:preprocessor (#10593) This commit is a preparation for upcoming changes to KeyChordSerialization for #7539 and #10203. In order to support variadic macros, /Zc:preprocessor was enabled, which required changing unrelated parts of the project. ## PR Checklist * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Project still compiles ✔️
2021-07-14 01:00:11 +02:00
<ClInclude Include="FileUtils.h" />
<ClInclude Include="HashUtils.h" />
Show only latest VS, VC prompts by default (#11326) ## Summary of the Pull Request Similar to `vswhere -latest`, show only the latest Visual Studio command prompts / developer PowerShell. This was tested by deleting the local package state and testing against fresh state with both VS2019 and VS2022 Preview installed, and indeed VS2022 Preview (both cmd and powershell) show. The other profiles were generated but hidden by default. ## References Modification of PR #7774 ## PR Checklist * [x] Closes #11307 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] 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. * [x] 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 ## Detailed Description of the Pull Request / Additional comments The sort algorithm is the same basic algorithm I used in https://github.com/microsoft/vswhere. It sorts first by installation version with a secondary sort based on the install date in case the installation versions are the same. ## Validation Steps Performed With both VS2019 and VS2022 Preview installed, I made sure the initial state was expected, and tried different combinations of hiding and unhiding generated entries, and restarted Terminal to make sure my settings "stuck".
2021-09-30 00:03:05 +02:00
<ClInclude Include="VisualStudioGenerator.h">
Add profile generators for Visual Studio (#7774) This commit adds dynamic profile generators for Visual Studio Developer Command Prompt (VS2017+) and Visual Studio Developer PowerShell (VS2019.2+) Tested manually by deploying locally. My local environment has four instances of VS installed, one VS2017 and multiple channels of VS2019. We're wrapping the COM Visual Studio Setup Configuration API to query for VS instances and retrieve the relevant properties. Two different namespaces are used so the end-user can turn off one or the other. For instance, end user may prefer to always use Developer PowerShell. ## Validation Steps Performed 1. Build locally using Visual Studio 2019 2. Deploy CascadiaPackage 3. Verify entries exist in profiles menu 4. Verify entries exist in settings.json 5. Open each profile 6. Validate start-in directory 7. Validate environment variables are as expected 8. Uninstall Windows Terminal - Dev package 9. Repeat. Closes #3821
2021-09-16 00:20:06 +02:00
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="VsDevCmdGenerator.h">
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="VsDevShellGenerator.h">
<Filter>profileGeneration</Filter>
</ClInclude>
<ClInclude Include="VsSetupConfiguration.h">
<Filter>profileGeneration</Filter>
</ClInclude>
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 18:56:59 +02:00
</ItemGroup>
<ItemGroup>
<Midl Include="ActionArgs.idl" />
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-05 06:50:13 +02:00
<Midl Include="ActionMap.idl" />
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 18:56:59 +02:00
<Midl Include="ColorScheme.idl" />
<Midl Include="Command.idl" />
<Midl Include="GlobalAppSettings.idl" />
<Midl Include="Profile.idl" />
<Midl Include="TerminalWarnings.idl" />
<Midl Include="CascadiaSettings.idl" />
Move IconSourceConverter from TerminalApp to TSM The Settings UI will need to take a dependency on IconSourceConverter.
2020-11-05 01:55:16 +01:00
<Midl Include="KeyChordSerialization.idl" />
Introduce public enum name<->value mappings to TSM The settings UI will eventually need to know about the available enum values for a given field. This offers that capability.
2020-11-03 18:56:04 +01:00
<Midl Include="EnumMappings.idl" />
Move IconSourceConverter from TerminalApp to TSM The Settings UI will need to take a dependency on IconSourceConverter.
2020-11-05 01:55:16 +01:00
<Midl Include="IconPathConverter.idl" />
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 12:43:30 +02:00
<Midl Include="TerminalSettings.idl" />
<Midl Include="AppearanceConfig.idl" />
<Midl Include="IAppearanceConfig.idl" />
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 19:08:46 +02:00
<Midl Include="FontConfig.idl" />
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 12:43:30 +02:00
<Midl Include="DefaultTerminal.idl" />
Enable /Zc:preprocessor (#10593) This commit is a preparation for upcoming changes to KeyChordSerialization for #7539 and #10203. In order to support variadic macros, /Zc:preprocessor was enabled, which required changing unrelated parts of the project. ## PR Checklist * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Project still compiles ✔️
2021-07-14 01:00:11 +02:00
<Midl Include="ApplicationState.idl" />
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 18:56:59 +02:00
</ItemGroup>
<ItemGroup>
<None Include="packages.config" />
</ItemGroup>
<ItemGroup>
<Filter Include="profileGeneration">
<UniqueIdentifier>{c81be61b-0d58-4277-8fd1-fcc888c3da9c}</UniqueIdentifier>
</Filter>
<Filter Include="json">
<UniqueIdentifier>{81a6314f-aa5b-4533-a499-13bc3a5c4af0}</UniqueIdentifier>
</Filter>
</ItemGroup>
Further reduce number of generated VS profiles (#11489) This commit reduces the number of generated VS profiles from 6 down to just 2 per VS instance. The reason we did this is out of concern of overwhelming or annoying new users with too many profiles. Especially since it's far easier at the moment to add new generators compared to removing them. As before only the latest instance is not hidden by default. ## PR Checklist * [x] I work here * [x] Tests added/passed * [x] As discussed in a Team Sync meeting ## Validation Steps Performed * Installed Visual Studio 2019 and 2022 Preview * A profile for both is generated, while the 2019 one is hidden by default ✔️ * $env:VSCMD_ARG_TGT_ARCH is x64 on my AMD64 machine ✔️
2021-10-20 01:52:00 +02:00
</Project>
Reference in a new issue Copy permalink