Add Extensions page to Settings UI #18559

carlos-zamora · 2025-02-11T00:50:05Z

Summary of the Pull Request

Adds an Extensions page to the Settings UI. This lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model.

Detailed Description of the Pull Request / Additional comments

Settings Model changes:
- FragmentSettings represents a parsed json fragment extension.
- FragmentProfileEntry and FragmentColorSchemeEntry are used to track profiles and color schemes added/modified
Editor changes - view models:
- ExtensionsViewModel operates as the main view model for the page.
- FragmentProfileViewModel and FragmentColorSchemeViewModel are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI!
- ExtensionPackageViewModel is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.)
Editor changes - views:
- Extensions.xaml uses a lot of data templates. These are reused in ItemsControls to display extension components.

Follow-ups

Collect and display some package metadata (i.e. icon, package name, etc.) for fragment extensions added from an AppExtension
- include a deep link to the settings app so you can manage the package
Streamline a process for adding extensions from the new page

carlos-zamora · 2025-02-19T20:30:12Z

Demo

carlos-zamora · 2025-02-19T20:32:08Z

src/cascadia/TerminalSettingsEditor/AddProfile.xaml

@@ -59,7 +59,7 @@
                                <IconSourceElement Grid.Column="0"
                                                   Width="16"
                                                   Height="16"
-                                                   IconSource="{x:Bind mtu:IconPathConverter.IconSourceWUX(Icon), Mode=OneTime}" />
+                                                   IconSource="{x:Bind mtu:IconPathConverter.IconSourceWUX(EvaluatedIcon), Mode=OneTime}" />


📝 Admittedly, a drive by. Happy to pull this out into a separate PR if desired.

carlos-zamora · 2025-02-19T20:33:43Z

src/cascadia/TerminalSettingsEditor/CommonResources.xaml

@@ -1199,7 +1199,7 @@
        <Setter Property="HorizontalAlignment" Value="Stretch" />
        <Setter Property="CornerRadius" Value="{ThemeResource ControlCornerRadius}" />
        <Setter Property="VerticalAlignment" Value="Stretch" />
-        <Setter Property="HorizontalContentAlignment" Value="Left" />
+        <Setter Property="HorizontalContentAlignment" Value="Stretch" />


📝 Had to update this style a bit to enable functionality for showing "Disabled" on the right side when an extension was disabled.

The way I made that work is that we have a 2-column grid. We need the grid to take up the entire horizontal content, so we need to set HorizontalContentAlignmen to stretch

carlos-zamora · 2025-02-19T20:38:44Z

src/cascadia/TerminalSettingsEditor/NewTabMenu.xaml

-            <!--  TODO CARLOS: Icon  -->
+            <!--  TODO GH #18281: Icon  -->


📝 This one's on me 😅

carlos-zamora · 2025-02-19T20:40:32Z

src/cascadia/TerminalSettingsEditor/SettingContainerStyle.xaml

@@ -227,6 +227,45 @@
        </Setter>
    </Style>

+    <!--  A basic setting container displaying immutable text as content  -->
+    <Style x:Key="SettingContainerWithTextContent"


📝 Used to display the Scope for an extension. Also allowed me to apply the SecondaryTextBlockStyle to the text shown on the right side (aka the value of Scope)

src/cascadia/TerminalSettingsModel/GlobalAppSettings.cpp

carlos-zamora · 2025-02-19T20:52:19Z

src/cascadia/TerminalSettingsEditor/Extensions.cpp

+            for (const auto&& entry : fragExt.ModifiedProfilesView())
+            {
+                // Ensure entry successfully modifies a profile before creating and registering the object
+                if (const auto& deducedProfile = _settings.FindProfile(entry.ProfileGuid()))
+                {
+                    auto vm = winrt::make<FragmentProfileViewModel>(entry, fragExt, deducedProfile);
+                    currentProfilesModified.push_back(vm);
+                    if (extensionEnabled)
+                    {
+                        profilesModifiedTotal.push_back(vm);
+                    }
+                }
+            }
+
+            for (const auto&& entry : fragExt.NewProfilesView())
+            {
+                // Ensure entry successfully points to a profile before creating and registering the object.
+                // The profile may have been removed by the user.
+                if (const auto& deducedProfile = _settings.FindProfile(entry.ProfileGuid()))
+                {
+                    auto vm = winrt::make<FragmentProfileViewModel>(entry, fragExt, deducedProfile);
+                    currentProfilesAdded.push_back(vm);
+                    if (extensionEnabled)
+                    {
+                        profilesAddedTotal.push_back(vm);
+                    }
+                }
+            }
+
+            for (const auto&& entry : fragExt.ColorSchemesView())
+            {
+                for (const auto& schemeVM : _colorSchemesPageVM.AllColorSchemes())
+                {
+                    if (schemeVM.Name() == entry.ColorSchemeName())
+                    {
+                        auto vm = winrt::make<FragmentColorSchemeViewModel>(entry, fragExt, schemeVM);
+                        currentColorSchemesAdded.push_back(vm);
+                        if (extensionEnabled)
+                        {
+                            colorSchemesAddedTotal.push_back(vm);
+                        }
+                    }
+                }
+            }


I'm only displaying the ones that were added successfully and point to something that already exists.

Long-term, do we want to do more here? Perhaps show the ones that weren't added successfully? I'm just not sure what the next steps would be and how we would want to approach this issue.

src/cascadia/TerminalSettingsModel/GlobalAppSettings.cpp

DHowett

Stake: I want to be the second reviewer on this :)

DHowett

Reviewed everything inside TerminalSettingsModel

I'm wondering if there's something we can do to make all of this cheaper. We're now storing JSON blobs - sometimes multiple times (parsed and regenerated at different nesting levels) - for every fragment and every generated profile... for a scenario that 9/10 launches aren't going to experience (most people probably do not enter the settings UI, right?)

DHowett · 2025-04-18T20:15:57Z

src/cascadia/TerminalSettingsModel/CascadiaSettings.idl

@@ -8,6 +8,12 @@ import "DefaultTerminal.idl";

 namespace Microsoft.Terminal.Settings.Model
 {
+    enum FragmentScope
+    {


DHowett · 2025-04-18T20:16:33Z

src/cascadia/TerminalSettingsModel/CascadiaSettings.idl

+        String Source { get; };
+        FragmentScope Scope { get; };
+        String Json { get; };
+        String JsonSource { get; };


💭 what's a JsonSource vs a Source and a Json?

DHowett · 2025-04-18T20:16:54Z

src/cascadia/TerminalSettingsModel/CascadiaSettings.idl

+    {
+        String ColorSchemeName { get; };
+        String Json { get; };
+        Boolean Conflict { get; };


💭 conflict, with what?

DHowett · 2025-04-18T20:18:47Z

src/cascadia/TerminalSettingsModel/CascadiaSettings.cpp

+        // copy fragment extensions
+        {
+            std::vector<Model::FragmentSettings> fragmentExtensions;
+            fragmentExtensions.reserve(_fragmentExtensions.Size());
+            for (const auto& fragment : _fragmentExtensions)
+            {
+                fragmentExtensions.emplace_back(get_self<FragmentSettings>(fragment)->Copy());
+            }
+            settings->_fragmentExtensions = winrt::single_threaded_vector(std::move(fragmentExtensions));
+        }
+
+        // copy dynamic profile generators
+        {
+            std::vector<Model::FragmentSettings> dynamicProfileGenerators;
+            dynamicProfileGenerators.reserve(_dynamicProfileGeneratorExtensions.Size());
+            for (const auto& fragment : _dynamicProfileGeneratorExtensions)
+            {
+                dynamicProfileGenerators.emplace_back(get_self<FragmentSettings>(fragment)->Copy());
+            }
+            settings->_dynamicProfileGeneratorExtensions = winrt::single_threaded_vector(std::move(dynamicProfileGenerators));
+        }


Alright, so, these are notionally immutable parts of the settings environment... right?

Since they're fully immutable, is there a strong need for us to deep clone them? The settings UI can't edit them after all, and they never get Saved.

same applies below

DHowett · 2025-04-18T20:20:27Z

src/cascadia/TerminalSettingsModel/CascadiaSettings.h

+            _scope{ scope },
+            _modifiedProfiles{ winrt::single_threaded_vector<Model::FragmentProfileEntry>() },
+            _newProfiles{ winrt::single_threaded_vector<Model::FragmentProfileEntry>() },
+            _colorSchemes{ winrt::single_threaded_vector<Model::FragmentColorSchemeEntry>() } {}


we will allocate three blank vectors for every kind of fragment and dynamic profile generator, the majority of which will never populate more than one of them.

DHowett · 2025-04-18T20:28:51Z