-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Add an Appearances xaml object and AppearanceViewModel to TSE #10066
Conversation
// These settings are not defined in AppearanceConfig, so we grab them | ||
// from the source profile itself. The reason we still want them in the | ||
// AppearanceViewModel is so we can continue to have the 'Text' grouping | ||
// we currently have in xaml, since that grouping has some settings that | ||
// are defined in AppearanceConfig and some that are not. | ||
OBSERVABLE_PROJECTED_SETTING(_appearance.SourceProfile(), FontFace); | ||
OBSERVABLE_PROJECTED_SETTING(_appearance.SourceProfile(), FontSize); | ||
OBSERVABLE_PROJECTED_SETTING(_appearance.SourceProfile(), FontWeight); |
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.
When we add unfocused appearance to the SUI, we will set a bool on these settings in xaml to only be shown for the default appearance (we do not want to add these settings to AppearanceConfig because we had concerns about causing a resize when transitioning between focused/unfocused states)
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.
That's fair. Pretty straightforward too. We'll just make their visibility depend on some bool in the view model. Kinda like how we used IsBaseLayer
to force all of the settings to always appear.
@msftbot make sure @carlos-zamora signs off on this. |
Hello @PankajBhojwani! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
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.
Looks good! Mostly just shuffling things around to introduce the AppearanceViewModel
. I have a few nits, but nothing major.
Windows.Foundation.Collections.IObservableVector<Font> CompleteFontList { get; }; | ||
Windows.Foundation.Collections.IObservableVector<Font> MonospaceFontList { get; }; |
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.
Can we keep these two on Profiles
? We'll be using the same font lists across all appearance configs so maybe we can just reuse them. Ideally, we could reuse the same list across all of the profile pages but that's definitely out of scope here haha.
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.
Hm, we would need to give AppearanceViewModel
a reference to the ProfileViewModel
then...
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.
IIRC MainPage
passes in some sort of "state" to every new page it navigates to right? Perhaps the font lists (or maybe even some sort of font list manager obj) could be passed into any new profile that's navigated to? LMK if I'm missing a part of the puzzle tho 😄
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 the ProfileViewModel
already had the font lists, the issue here is how the Appearances
or AppearanceViewModel
can get access to the font lists in ProfileViewModel
.
Just made a change to give the Appearances
object a ref to the ProfileViewModel
, so it grabs the font lists from there now!
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.
Yup! MainPage
can totally pass in the font lists via the NavigationState
. And that's probably the architecture we'll want. That way, we'll only ever generate the font lists once, and we can reuse them across each Profiles
page.
The only reason I think we should hold off on that change rn is I think the right approach would be to lazy load them. Like, I'm running into a similar problem with the Actions page right now. If we had MainPage
load up all of the actions and all of the fonts when you open the SUI, it'll take forever to open it.
Mind filing a task so that we do this later (probably in the v2.0 timeframe)? I think it's worth doing, just not in this PR. I've added this as a part of #9207.
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 do not think we should continue using NavigationState
as a bad viewmodel. We need a viewmodel. Navigation state objects are supposed to get temporary information into a page that is necessary TO NAVIGATE. If we have a real viewmodel, we don't even need a navigation state class.
// These settings are not defined in AppearanceConfig, so we grab them | ||
// from the source profile itself. The reason we still want them in the | ||
// AppearanceViewModel is so we can continue to have the 'Text' grouping | ||
// we currently have in xaml, since that grouping has some settings that | ||
// are defined in AppearanceConfig and some that are not. | ||
OBSERVABLE_PROJECTED_SETTING(_appearance.SourceProfile(), FontFace); | ||
OBSERVABLE_PROJECTED_SETTING(_appearance.SourceProfile(), FontSize); | ||
OBSERVABLE_PROJECTED_SETTING(_appearance.SourceProfile(), FontWeight); |
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.
That's fair. Pretty straightforward too. We'll just make their visibility depend on some bool in the view model. Kinda like how we used IsBaseLayer
to force all of the settings to always appear.
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're close. Just move those two properties into the AppearanceViewModel
and we'll be good.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
pretty straightforward all things considered! just a big nit.
As #10317 targets this, please don't automerge this! |
Summary of the Pull Request
Implements an
Appearances
xaml object and anAppearanceViewModel
in the SettingsEditor project. UpdatesProfiles
to use these new objects for its default appearance.This is the first step towards getting
UnfocusedAppearance
into the SUI.