Introduce setting override tracking and update SettingContainer#9079
Conversation
carlos-zamora
left a comment
There was a problem hiding this comment.
I'm chatting with @cinnamon-msft after lunch to do a bit of wordsmithing.
| // '{}' was not found | ||
| // fallback to more ambiguous version | ||
| hstring overrideMsg{ fmt::format(std::wstring_view{ RS_(L"SettingContainer_OverrideIntro") }, RS_(L"SettingContainer_OverrideTarget")) }; | ||
| tb.Text(overrideMsg); |
There was a problem hiding this comment.
This should only happen if the localization was messed up. Idk if there's a way to get around this? Or handle it better?
| // Hook up the hyperlinks from SettingContainer | ||
| _RegisterNavigationHandlers(GeneralStack()); | ||
| _RegisterNavigationHandlers(AppearanceStack()); | ||
| _RegisterNavigationHandlers(AdvancedStack()); |
There was a problem hiding this comment.
I'm not happy about this one. But we could leverage this to access the setting containers via code now.
| } | ||
| else | ||
| { | ||
| // TODO #1690: add special handling for proto-extensions here |
There was a problem hiding this comment.
Chatted with @PankajBhojwani about proto-extensions. This should mostly just work. Only changes that would be needed for proto-extensions are...
- tag profiles from proto-extensions
- use
Profile::Sourceto create msgTarget - add a hyperlink for a read-only view of the proto-extension
|
Some more annoying news. It looks like the screen reader doesn't read the hyperlink. I've tried explicitly setting the automation properties as well and no luck. Hyperlinks seem accessible in XAML Controls gallery. I'm worried this may be a XAML Islands issue? I'm looking more into that now. |
Check the About dialog |
The links in there are |
|
I don't expect that this is an islands-specific issue. |
|
Now that the text block is removed, we don't have the accessibility issue. |
zadjii-msft
left a comment
There was a problem hiding this comment.
I suppose these are all nits? But there's enough of them that I'm just gonna leave a comment for now.
src/cascadia/TerminalSettingsEditor/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
| <value>a lower layer</value> | ||
| <comment>This is the object of "SettingContainer_OverrideIntro".</comment> | ||
| <data name="SettingContainer_OverrideMessageBaseLayer" xml:space="preserve"> | ||
| <value>Reset to base layer value</value> |
There was a problem hiding this comment.
if we're only gonna do base layer, should we still add all of the source tracking? It seems our new needs are satisfied by the existence of Has/Clear in the model.
There was a problem hiding this comment.
We still need source tracking for a few reasons:
- need to specifically detect when we're overriding "base layer" as opposed to "in-box" or "generated" profile object
- we'll probably use some of this for telemetry
- in preparation for profile inheritance, we'll still need to distinguish a profile that exists from one that isn't exposed to the user
526eb92 to
500c38e
Compare
src/cascadia/TerminalSettingsEditor/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
| #include "SettingContainer.h" | ||
| #include "SettingContainer.g.cpp" | ||
| #include "LibraryResources.h" | ||
| #include "../TerminalSettingsModel/LegacyProfileGeneratorNamespaces.h" |
There was a problem hiding this comment.
is this required? Rather not include things directly out of TSM
There was a problem hiding this comment.
Ah, this was a relic of when we were detecting the specific profile generator. Removed.
There was a problem hiding this comment.
Had to add this back in to be able to detect when we're overriding a setting from the proto-extension vs one of our profile generators
| // no source; we're using the system-default value | ||
| tooltip = L""; | ||
| } | ||
| else if (const auto& profile{ settingSrc.try_as<Model::Profile>() }) |
There was a problem hiding this comment.
i </3 that SettingContainer knows what a profile is
There was a problem hiding this comment.
I concur - almost seems like we should have ProfileSettingContainer : SettingContainer that allows for reverting to the parent, but only for settings in profiles.
All this is terrible, but let's not pretend our settings model was designed for a GUI.
There was a problem hiding this comment.
Long-term, we should probably move more of this responsibility over the the view model in a post-#9207 world. But I think we're just not ready for that yet, unfortunately.
zadjii-msft
left a comment
There was a problem hiding this comment.
You know what, Dustin's got a lot more relevant comments than I do. If you can satisfy his concerns, I'll be happy here too
| // no source; we're using the system-default value | ||
| tooltip = L""; | ||
| } | ||
| else if (const auto& profile{ settingSrc.try_as<Model::Profile>() }) |
There was a problem hiding this comment.
I concur - almost seems like we should have ProfileSettingContainer : SettingContainer that allows for reverting to the parent, but only for settings in profiles.
All this is terrible, but let's not pretend our settings model was designed for a GUI.
|
Main thing I'm unsure about is the macros. I've broken them up and moved them closer to where they're used. Let me know what you think. |
|
There's some weird behavior here:
@cinnamon-msft what should the proper behavior here be. |
|
Had to make a minor modification for proto extension. If we're specifically overriding a value from a proto-extension, we want this reset button to appear. See the demo above for what that looks like. Design was discussed with @cinnamon-msft. @DHowett thoughts? |
| const auto profileSource{ profile.Source() }; | ||
| if (profileSource == WslGeneratorNamespace || | ||
| profileSource == AzureGeneratorNamespace || | ||
| profileSource == PowershellCoreGeneratorNamespace) | ||
| { | ||
| // from a dynamic profile generator | ||
| return {}; | ||
| } | ||
| else | ||
| { | ||
| // proto-extensions | ||
| return hstring{ fmt::format(std::wstring_view(RS_(L"SettingContainer_OverrideMessageProtoExtension")), profileSource) }; | ||
| } |
There was a problem hiding this comment.
I flatly reject a dependency from this UI element to an implementation detail in the settings model. You're going to have to find a better way to do this.
Maybe you need a "Fragment" origin.
There was a problem hiding this comment.
ok... can I get a bit more feedback here?
There was a problem hiding this comment.
Maybe you need to tag things that come from fragments as coming from fragments rather than coming from "Generated" to give them special behavior?
There was a problem hiding this comment.
The name is not going to be particularly pretty if it comes from a package. It will say, "value from: CanonicalGroupLtd.UbuntuOnWindows_7yabmiilazx1"
There was a problem hiding this comment.
ewwww. Understandable. Is there a way to detect that it came from a package or if it's going to have an ugly name? Maybe some way to polish the ugly name into a cleaner one?
There was a problem hiding this comment.
I'm ok with doing this for now, then revisiting it after some user feedback. We're going to have to reevaluate all of this work anyways :(
src/cascadia/TerminalSettingsEditor/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
Co-authored-by: Dustin L. Howett <[email protected]>
|
Looks like you'll have a conflict with #8414 |
|
Sorry, #9036. |
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
| auto childImpl{ matchingProfile->CreateChild() }; | ||
| childImpl->LayerJson(profileStub); | ||
| childImpl->Origin(OriginTag::Fragment); | ||
| childImpl->Source(source); |
There was a problem hiding this comment.
I removed this call in #9293, @carlos-zamora do we need it?
|
🎉 Handy links: |


This PR adds improved override message generation for inheritance in
SUI. The settings model now has an
OriginTagto be able to denotewhere a
Profilecame from. This tag is used in theSettingContainerto generate a more specific override message.
References
#6800 - SUI Epic
#8919 - SUI Inheritance PR
#8804 - SUI Inheritance (old issue)
Detailed Description of the Pull Request / Additional comments
PROJECTED_SETTINGas a macro to more easily declare thefunctions for each setting
<setting>OverrideSourcewhich finds theProfilethathas <setting> defined
OriginTag Profile::Origin {Custom, InBox, Generated}totrace where a profile came from
DefaultProfileUtilscreates profiles for profile generators. Sothat now sets the
Origintag toGeneratedCascadiaSettings::LoadDefaults()tags all profiles created asInBox.with
<setting>OverrideSourcedisplay for the target
Validation Steps Performed
Tested the following cases: