Skip to content

Layer the globals globals on top of the root globals#3031

Merged
zadjii-msft merged 2 commits intomasterfrom
dev/migrie/b/2906-globalization
Oct 4, 2019
Merged

Layer the globals globals on top of the root globals#3031
zadjii-msft merged 2 commits intomasterfrom
dev/migrie/b/2906-globalization

Conversation

@zadjii-msft
Copy link
Member

Summary of the Pull Request

Layer the globals globals on top of the root globals.

PR Checklist

Detailed Description of the Pull Request / Additional comments

We added the ability for the root to be used as the globals object in #2515. However, if you have a globals object, then the settings in the root will get ignored. That's bad. We should layer them.

@zadjii-msft zadjii-msft added Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. labels Oct 2, 2019
// initialRows should not be cleared here
}
})" };
const std::string settings3String{ R"(
Copy link
Member

Choose a reason for hiding this comment

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

Could you add another test:

        const std::string settings4String{ R"(
        {
            "initialRows": 345,
            "globals": {
                "defaultProfile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}"
                // initialRows should not be cleared here
            },
            "defaultProfile": "{6239a42c-2222-49a3-80bd-e8fdd045185c}"
        })" };

I think as of now, processing this will make defaultProfile {6239a42c-1111-49a3-80bd-e8fdd045185c} instead of {6239a42c-2222-49a3-80bd-e8fdd045185c}.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, but I think that's the expected behavior with this change unfortunately. Once we've parsed the json, it doesn't retain any of its original ordering any longer. I'm not sure how we'd be able to get the 2222 guid to be the default in that case.

Copy link
Member

Choose a reason for hiding this comment

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

Sure, but I think that's the expected behavior with this change unfortunately. Once we've parsed the json, it doesn't retain any of its original ordering any longer. I'm not sure how we'd be able to get the 2222 guid to be the default in that case.

Think it might be worth creating an issue then and just leaving it for later?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, i see: file level ordering. Interesting.

...

we can check getOffsetStart and getOffsetLimit 😉

Copy link
Member Author

Choose a reason for hiding this comment

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

gosh Dustin why'd you have to suggest that

That's certainly an option, but that's a lot harder. We'd have to do it on a peculiar property-by-property basis. Layering wouldn't just be "do I have this property? great, let's parse it". It's now "for the globals, do I have this property? was its getOffsetStart greater than the last time I layered this property?"

That takes it from a little change to a much, MUCH bigger change

@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 Oct 2, 2019
}
}

void SettingsTests::TestLayerGlobalsOnRoot()
Copy link
Member

@carlos-zamora carlos-zamora Oct 2, 2019

Choose a reason for hiding this comment

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

What if the user has multiple "globals"? Like the following:

"globals":{
   "defaultProfile": <val>
 },
"defaultProfile": <val>,
"globals":{
   "defaultProfile": <val>
}

This might be impacted by the other thread I started...

Copy link
Contributor

Choose a reason for hiding this comment

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

this is just gonna be invalid

Copy link
Member

Choose a reason for hiding this comment

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

Honestly, I'd kinda just prefer to remove the "globals" key in general. Then we'd get rid of all of these 😁

Copy link
Member Author

Choose a reason for hiding this comment

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

me too at this point. However, we haven't ever gotten to the point where we can safely say "we're breaking your settings now" unfortunately. Plus there's that C# tool out there for customizing our settings, and IIRC that tool uses the "globals" object :(

@miniksa
Copy link
Member

miniksa commented Oct 3, 2019

This is giving me a headache, so I'm going to let Carlos and Dustin be the reviewers as they seem to have a handle on it already. @ me if you really need me to look at this.

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.

Gracias

@zadjii-msft zadjii-msft merged commit 0691c21 into master Oct 4, 2019
@zadjii-msft zadjii-msft deleted the dev/migrie/b/2906-globalization branch January 31, 2020 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The globals object should be layered on the root settings object

4 participants