Skip to content

Move TerminalSettings from TermApp to TerminalSettingsModel - #9318

Merged
9 commits merged into
mainfrom
dev/cazamor/sui/move-term-sets
Mar 15, 2021
Merged

9 commits merged into
mainfrom
dev/cazamor/sui/move-term-sets

Conversation

@carlos-zamora

@carlos-zamora Carlos Zamora (carlos-zamora) commented Mar 1, 2021 •

Copy link
Copy Markdown

This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the TerminalSettings object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI.

TerminalSettings had to see a few more functions exposed in the IDL
(including some inheritance stuff).

Refresh the JSON to make TerminalSettings do it's thing across all the
open terminals.

References #9122 - Terminal Preview
References #6800 - SUI Epic

Comment on lines +42 to +49
Model::TerminalSettings MakeChild() { return *CreateChild(); }
void SetParent(Model::TerminalSettings parent)
{
ClearParents();
com_ptr<TerminalSettings> parentImpl;
parentImpl.attach(get_self<TerminalSettings>(parent));
InsertParent(0, parentImpl);
}

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are basically just exposing functions from IInheritable, except exposing them as projected types. Unfortunately, that's why the name of these has to be something similar, but not the same thing.

I could update IInheritable to return projected types, then expose these functions in the IDL. But it feels really weird to expose inheritance outside of TSM. I guess TerminalSettings gets to be special in that way?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TerminalSettings should always have only one parent. So SetParent makes sense as a name, even though the contents look a bit weird (because IInheritable is designed to handle multiple parents)

@carlos-zamora
Carlos Zamora (carlos-zamora) marked this pull request as ready for review March 4, 2021 02:11

@zadjii-msft Mike Griese (zadjii-msft) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is largely mechanical

void TerminalPage::_OpenNewTab(const NewTerminalArgs& newTerminalArgs)
try
{
auto [profileGuid, settings] = TerminalSettings::BuildSettings(_settings, newTerminalArgs, *_bindings);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow crazy how many times we were actually using the guid in the return value of this function too. Shame WinRT won't let us return the pair. Shame.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't love that this responsibility moved into TSM but ok.

@@ -0,0 +1,135 @@
/*++

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow I hate that the github diff for this cannot figure out the file was renamed

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for future reviewers:

git diff --word-diff main:src/cascadia/TerminalApp/TerminalSettings.h origin/dev/cazamor/sui/move-term-sets:src/cascadia/TerminalSettingsModel/TerminalSettings.h

that'll give you the diff for this file by words. Spoiler: it's just renaming namespaces

@zadjii-msft Mike Griese (zadjii-msft) removed their assignment Mar 8, 2021

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nits.

void TerminalPage::_OpenNewTab(const NewTerminalArgs& newTerminalArgs)
try
{
auto [profileGuid, settings] = TerminalSettings::BuildSettings(_settings, newTerminalArgs, *_bindings);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't love that this responsibility moved into TSM but ok.

try
{
TerminalApp::TerminalSettings controlSettings;
TerminalSettings controlSettings;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This constructs an empty TerminalSettings. Is that intended? Make sure it's intended.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it isn't. I've changed it to TerminalSettings controlSettings{nullptr}.

This should've been happening before though so the change shouldn't do anything (other than avoiding the construction of an unused TerminalSettings). Right?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be very, very sure none of the control flows below this initialization relied on it not being null. I can imagine a world where the conditionals fail but then we initialize a terminal with the "default settings".

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here's all the possibilities:

  1. splitMode == Duplicate
  • current_guid found
    • ✔️ controlSettings is set to CreateWithProfileByID (never null)
  • current_guid not found
    • profileFound stays as false, process to step 2
  1. splitMode != Duplicate (so profileFound stays as false)
  • ✔️ controlSettings is set to CreateWithNewTerminalArgs (based on CreateWithProfileByID, so never null)

We could rewrite this to be more like this?

// NOTE: we could 
const auto current_guid{ focusedTab->GetFocusedProfile() };
if (splitMode == SplitType::Duplicate && current_guid)
{
	// set realGuid and controlSettings
	// update working directory
}
else 
{
	// set realGuid and controlSettings
}

That way it would be more clear that we're always setting realGuid and controlSettings. Thoughts?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as it is provable that there is no codepath that tries to initialize with a null settings, I am okay accepting this.

@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 Mar 10, 2021
@DHowett

Copy link
Copy Markdown
Member

Fix the conflicts and let's go!

@DHowett Dustin L. Howett (DHowett) changed the title Move TerminalSettings from TermApp to TSM Move TerminalSettings from TermApp to TerminalSettingsModel Mar 15, 2021
@DHowett Dustin L. Howett (DHowett) added the AutoMerge Marked for automatic merge by the bot when requirements are met label Mar 15, 2021
@ghost

Copy link
Copy Markdown

Hello Dustin L. Howett (@DHowett)!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@ghost
ghost merged commit 44f1ba6 into main Mar 15, 2021
@ghost
ghost deleted the dev/cazamor/sui/move-term-sets branch March 15, 2021 23:15
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AutoMerge Marked for automatic merge by the bot when requirements are met 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