Skip to content
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

Merged
merged 31 commits into from
Jul 9, 2021

Conversation

PankajBhojwani
Copy link
Contributor

@PankajBhojwani PankajBhojwani commented May 10, 2021

Summary of the Pull Request

Implements an Appearances xaml object and an AppearanceViewModel in the SettingsEditor project. Updates Profiles to use these new objects for its default appearance.

This is the first step towards getting UnfocusedAppearance into the SUI.

Comment on lines 59 to 66
// 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);
Copy link
Contributor Author

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)

Copy link
Member

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.

@PankajBhojwani PankajBhojwani marked this pull request as ready for review May 11, 2021 07:58
@PankajBhojwani
Copy link
Contributor Author

@msftbot make sure @carlos-zamora signs off on this.

@ghost ghost added the AutoMerge Marked for automatic merge by the bot when requirements are met label May 11, 2021
@ghost
Copy link

ghost commented May 11, 2021

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:

  • I'll only merge this pull request if it's approved by @carlos-zamora

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".

@PankajBhojwani PankajBhojwani removed the AutoMerge Marked for automatic merge by the bot when requirements are met label May 11, 2021
Copy link
Member

@carlos-zamora carlos-zamora left a 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.

Comment on lines 23 to 24
Windows.Foundation.Collections.IObservableVector<Font> CompleteFontList { get; };
Windows.Foundation.Collections.IObservableVector<Font> MonospaceFontList { get; };
Copy link
Member

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.

Copy link
Contributor Author

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...

Copy link
Contributor

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 😄

Copy link
Contributor Author

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!

Copy link
Member

@carlos-zamora carlos-zamora May 14, 2021

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.

Copy link
Member

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.

src/cascadia/TerminalSettingsEditor/Appearances.h Outdated Show resolved Hide resolved
Comment on lines 59 to 66
// 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);
Copy link
Member

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.

src/cascadia/TerminalSettingsEditor/Appearances.cpp Outdated Show resolved Hide resolved
Copy link
Member

@carlos-zamora carlos-zamora left a 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.

src/cascadia/TerminalSettingsEditor/Appearances.cpp Outdated Show resolved Hide resolved
@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels May 14, 2021
@ghost

This comment has been minimized.

@PankajBhojwani PankajBhojwani added the Needs-Second It's a PR that needs another sign-off label Jun 1, 2021
@ghost ghost requested review from zadjii-msft, miniksa and lhecker June 1, 2021 16:36
@carlos-zamora

This comment has been minimized.

Copy link
Member

@DHowett DHowett left a 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.

src/cascadia/TerminalSettingsEditor/Appearances.h Outdated Show resolved Hide resolved
@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jun 16, 2021
@PankajBhojwani
Copy link
Contributor Author

As #10317 targets this, please don't automerge this!

@DHowett DHowett changed the title Add an Appearances xaml object and an AppearanceViewModel to SettingsEditor Add an Appearances xaml object and AppearanceViewModel to TSE Jul 9, 2021
@DHowett DHowett merged commit c18e0f5 into main Jul 9, 2021
@DHowett DHowett deleted the dev/pabhoj/sui_appearances branch July 9, 2021 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Second It's a PR that needs another sign-off
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants