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 ✔️
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 #1790Closes#6049
## Summary of the Pull Request
`ApplicationLanguages::PrimaryLanguageOverride` requires packaged activation.
This PR prevents any such application crashes, by skipping any calls to `PrimaryLanguageOverride`, as well as hiding the language selector in the settings UI.
## PR Checklist
* [x] I work here
* [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.
## Validation Steps Performed
When WT is run unpackaged:
* Doesn't crash during start ✔️
* SUI doesn't show the language selector ✔️
## Summary of the Pull Request
Check for null before serializing the default terminal. Because the _currentDefaultTerminal is only initialized when the `Launch` page is navigated to, this _could_ be null if you navigate to another page, save, then save again.
## PR Checklist
* [x] Closes#10003
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
It crashed consistently before, it doesn't now.
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.
- Whenever we add a new profile setting from now on we have to update
`Profile::CopySettings` _and_ `CascadiaSettings::DuplicateProfile` 👎
Notes from bug bash (checked bugs have been resolved):
- [ ] The duplicate list can be very long if you have profiles
- [x] DH: "Create new" seems too vague. "New empty profile" or something
seems a little clearer to me.
- [x] There is no deduplication counter for name
- [x] Crash when your settings file is corrupt and we had to fall back
to the defaults and you duplicate a profile
- [x] Crash due to #10003
## PR Checklist
* [x] Closes#9121
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
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9714
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
Attempts to generate a name Profile X, where X is the index of the new profile (1-based).
As long as name is already taken, generates new name by incrementing X by 1
This pull request adds an appearance configuration object to our
settings model and app lib, allowing the control to be rendered
differently depending on its state, and then uses it to add support for
an "unfocused" appearance that the terminal will use when it's not in
focus.
To accomplish this, we isolated the appearance-related settings from
Profile (into AppearanceConfig) and TerminalSettings (into the
IControlAppearance and ICoreAppearance interfaces). A bunch of work was
done to make inheritance work.
The unfocused appearance inherits from the focused one _for that
profile_. This is important: If you define a
defaults.unfocusedAppearance, it will apply all of defaults' settings to
any leaf profile when a terminal in that profile is out of focus.
Specified in #8345Closes#3062Closes#2316
**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.
`CascadiaSettings::UpdateColorSchemeReferences` had two bugs in it:
1. we would never check/update the base layer
2. we would explicitly set the color scheme on a profile referencing the
old name
This PR fixes both of those issues by checking/updating the base layer,
and ensuring that we check if a profile has an explicit reference before
updating it.
Since the affected code is in TSM, I also created an automated local
test.
## Validation Steps Performed
Bug repro steps.
Specifically tested [DHowett's scenario] too.
Test added.
Closes#9094
[DHowett's scenario]: https://github.com/microsoft/terminal/issues/9094#issuecomment-776412781
## Summary of the Pull Request
This fixes a bug where renaming/deleting a color scheme would not update profiles that referenced it.
This also adds detection for renaming a color scheme to a name that is already in use, and adds appropriate UI for that.
## References
#6800 - Settings UI Epic
## PR Checklist
* [X] Closes#8756
## Detailed Description of the Pull Request / Additional comments
`Model::CascadiaSettings` was updated to have a `UpdateColorSchemeReferences()` function that updates all profiles referencing the newly renamed color scheme.
`Editor::ColorSchemesPageNavigationState` now takes and exposes a `Model::CascadiaSettings`.
When a color scheme is renamed or deleted, we use `CascadiaSettings` to update our list of color schemes appropriately, then call `UpdateColorSchemeReferences()` to update the profiles.
The tricky part is that `Profile` does not store a direct reference to `ColorScheme`, but rather the name of the color scheme. See [this tread](https://github.com/microsoft/terminal/issues/8756#issuecomment-760375027) for a discussion on this topic.
## Validation Steps Performed
Repro steps from #8756 when renaming/deleting a referenced color scheme.
## Demo
This commit is an amalgamation of some of the TSM changes in PR #8048.
It:
* Introduces CascadiaSettings.CreateNewProfile to add a new profile
* Introduces CascadiaSettings.ProfileDefaults, which returns the
"defaults" object as a profile
* Fixes the font weight deserializer to work on uint16_ts
* Fixes a property getter in ColorScheme to not be a property getter
* Fixes a reserialization error with default profiles
* Sets a default icon for all profiles (to the C:\ Segoe MDL2 icon)
Show a validation warning when someone sets a `setColorScheme` action
with an invalid scheme
In the setting validation phase, scan all commands for all the "set
color scheme" actions, and check each of them has a valid scheme. If any
of them has an invalid scheme name, raise a warning. Do not check
iterable commands that will be expanded to valid color schemes.
## Validation Steps Performed
- Added tests to LocalTests_SettingsModel
- Manual tests, add commands to settings.json with invalid color scheme
and check the warning pops up. Try simple and nested commands.
Closes#7221
## 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
## Summary of the Pull Request
This PR replaces `CascadiaSettings::_profiles` with...
- `_allProfiles`: the list of all available profiles in the settings model (i.e. settings.json, dynamic profiles, etc...)
- `_activeProfiles`: the list of all non-hidden profiles (used for the new tab dropdown)
## References
#8018: maintaining a list of all profiles allows us to serialize hidden profiles
#1564: Settings UI can link to `AllProfiles()` instead of `ActiveProfiles()` to expose hidden profiles
## PR Checklist
* [x] Closes#4139
* [x] Tests added/passed
## Validation Steps Performed
Deploy and testing succeeded
## Summary of the Pull Request
Introduces `IInheritable` as an interface that helps move cascading settings into the Terminal Settings Model. `GlobalAppSettings` and `Profile` both are now `IInheritable`. `CascadiaSettings` was updated to `CreateChild()` for globals and each profile when we are loading the JSON data.
IInheritable does most of the heavy lifting. It introduces a two new macros and the interface. The macros help implement the fallback functionality for nullable and non-nullable settings.
## References
#7876 - Spec Addendum
#6904 - TSM Spec
#1564 - Settings UI
#7876 - `Copy()` needs to be updated to include _parent
We wrap the call to `_WriteSettings` in
`CascadiaSettingsSerialization.cpp` in a try/catch block, and if we
catch an error we append a warning telling the user to check the
permissions on their settings file.
Closes#7727
## Summary of the Pull Request
This implements the `Copy` function for `CascadiaSettings`. Copy performs a deep copy of a `CascadiaSettings` object. This is needed for data binding in the Terminal Settings Editor.
The `Copy` function was basically implemented in every settings model object. This was mostly just repetitive work.
## References
#7667 - TSM
#1564 - Settings UI
## PR Checklist
* [X] Tests added/passed
## Summary of the Pull Request
Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source.
This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist.
## References
Based on #7667
## PR Checklist
* [X] Closes#7784
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
## Validation Steps Performed
Deploy succeeded.
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
Renamed from src/cascadia/TerminalApp/CascadiaSettings.cpp (Browse further)
