-
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
Allow empty strings, %Environment-Variable% references in profile "icon" settings - fixes #1468, #1867 #2050
Allow empty strings, %Environment-Variable% references in profile "icon" settings - fixes #1468, #1867 #2050
Conversation
…on" settings - fixes bugs 1468, 1867 First, I tried reusing the existing ExpandEnvironmentVariableStrings() helper in TerminalApp/CascadiaSettings.cpp, but then I realized that WIL already provides its own wrapper for ExpandEnvironmentStrings(), so instead I deleted ExpandEnvironmentVariableStrings() and replaced its usages with wil::ExpandEnvironmentStringsW(). I then used wil::ExpandEnvironmentStringsW() when resolving the icon path as well. In addition, to allow empty strings, I made changes to treat empty strings for "icon" the same as JSON `null` or not setting the property at all.
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 is awesome. Just a couple minor questions and suggestions.
As for [1]: should we just knock it out for background image as well? That suggests that functions that return paths out of Profile should just pre-expand them (but never store them expanded, because reserialization would be depressing), except with the notable (and commentable!) exception of command line, which we can just leave up to CreateProcess
src/cascadia/TerminalApp/App.cpp
Outdated
auto path = profile.GetIconPath(); | ||
winrt::hstring iconPath{ path }; | ||
std::wstring path{ profile.GetIconPath() }; | ||
std::wstring envExpandedPath{ wil::ExpandEnvironmentStringsW<std::wstring>(path.data()) }; |
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.
should we expand these here or in GetIconPath
? Either way, we'll need to issue a settings reload when we get the window message indicating that the environment changed (#1125), but perhaps it'll make easier the comment I'm about to leave at the end of the review [1]
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 could go either way on this. Initially I had the expansion done in Profile.GetIconPath(); I changed it because I felt it would be inconsistent with other code in Profile. But see my reply to your point [1].
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 meant to mark "request changes")
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.
As for [1]: should we just knock it out for background image as well? That suggests that functions that return paths out of Profile should just pre-expand them (but never store them expanded, because reserialization would be depressing), except with the notable (and commentable!) exception of command line, which we can just leave up to CreateProcess
If we change to expand variables in all of Profile's file path strings other than commandLine
, we'd also have to change some of the special handling for startingDirectory
, which already expands variables as well. That might be a bigger change than would reasonably fit in a single PR. What do you think?
src/cascadia/TerminalApp/App.cpp
Outdated
auto path = profile.GetIconPath(); | ||
winrt::hstring iconPath{ path }; | ||
std::wstring path{ profile.GetIconPath() }; | ||
std::wstring envExpandedPath{ wil::ExpandEnvironmentStringsW<std::wstring>(path.data()) }; |
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 could go either way on this. Initially I had the expansion done in Profile.GetIconPath(); I changed it because I felt it would be inconsistent with other code in Profile. But see my reply to your point [1].
@@ -20,122 +20,4 @@ | |||
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware> | |||
</windowsSettings> | |||
</application> | |||
<!-- |
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 sure why, but the bcz
build itself seems to keep changing this file. Should I leave the changes? They seem similar to changes that were manually done in PR #2043 so I hope they're not bad.
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.
Yeah, I think it's fine. And that one is already merged. @DHowett-MSFT would be able to confirm.
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.
Oh shiz, that's actually a really good catch. I'll file a task to fix this the right way. Basically #2043 needs to get applied to these tests too.
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.
(for know this is fine)
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.
@@ -20,122 +20,4 @@ | |||
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware> | |||
</windowsSettings> | |||
</application> | |||
<!-- |
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.
Yeah, I think it's fine. And that one is already merged. @DHowett-MSFT would be able to confirm.
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 guess I left comments and should request changes, not approve.
I very much want to start using this |
Co-Authored-By: Michael Niksa <[email protected]>
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 great to me!
@DHowett-MSFT, please take another look. |
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.
Thanks!
…icrosoft#1468, microsoft#1867 (microsoft#2050) First, I tried reusing the existing ExpandEnvironmentVariableStrings() helper in TerminalApp/CascadiaSettings.cpp, but then I realized that WIL already provides its own wrapper for ExpandEnvironmentStrings(), so instead I deleted ExpandEnvironmentVariableStrings() and replaced its usages with wil::ExpandEnvironmentStringsW(). I then used wil::ExpandEnvironmentStringsW() when resolving the icon path as well. In addition, to allow empty strings, I made changes to treat empty strings for "icon" the same as JSON `null` or not setting the property at all. Co-Authored-By: Michael Niksa <[email protected]>
🎉 Handy links: |
Summary of the pull request
Previously, trying to set the
"icon"
property of a settings profile to either the empty string or a string containing%environment variable names%
would cause Terminal to crash when loading that profile into the profile selection menu. Now, empty strings for"icon"
are treated the same as JSONnull
or not setting the property at all, and environment variable references in the"icon"
value are expanded.Detailed description of the pull request / Additional comments
To expand environment variables, I first tried reusing the existing ExpandEnvironmentVariableStrings() helper in TerminalApp/CascadiaSettings.cpp, but then I remembered that the Windows Implementation Libraries already provide their own wrapper for ExpandEnvironmentStrings(), so instead I deleted ExpandEnvironmentVariableStrings() and replaced its existing usages with wil::ExpandEnvironmentStringsW(). I then used wil::ExpandEnvironmentStringsW() when resolving the icon path as well.
Validation steps performed
Manual testing by taking a default
profiles.json
file and changing the'"icon"
value for one profile, with empty string and with strings containing%ProgramFiles%
at the start.PR Checklist
I wasn't sure where to add these. It seems like the best place would be in ut_app/SettingsTests.cpp but that file has a comment that due to TerminalSettings and other WinRT types, it doesn't work right in Azure DevOps CI?