-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce setting override tracking and update SettingContainer #9079
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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::Source
to 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -5,6 +5,7 @@ | |||
#include "SettingContainer.h" | |||
#include "SettingContainer.g.cpp" | |||
#include "LibraryResources.h" | |||
#include "../TerminalSettingsModel/LegacyProfileGeneratorNamespaces.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this required? Rather not include things directly out of TSM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this was a relic of when we were detecting the specific profile generator. Removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i </3 that SettingContainer knows what a profile is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok... can I get a bit more feedback here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 (
|
@@ -590,6 +597,8 @@ void CascadiaSettings::_ParseAndLayerFragmentFiles(const std::unordered_set<std: | |||
// (we add a new inheritance layer) | |||
auto childImpl{ matchingProfile->CreateChild() }; | |||
childImpl->LayerJson(profileStub); | |||
childImpl->Origin(OriginTag::Fragment); | |||
childImpl->Source(source); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
OriginTag
to be able to denotewhere a
Profile
came from. This tag is used in theSettingContainer
to 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_SETTING
as a macro to more easily declare thefunctions for each setting
<setting>OverrideSource
which finds theProfile
thathas <setting> defined
OriginTag Profile::Origin {Custom, InBox, Generated}
totrace where a profile came from
DefaultProfileUtils
creates profiles for profile generators. Sothat now sets the
Origin
tag toGenerated
CascadiaSettings::LoadDefaults()
tags all profiles created asInBox
.with
<setting>OverrideSource
display for the target
Validation Steps Performed
Tested the following cases: