-
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
Initialize Terminal Preview settings from Terminal settings #12907
Initialize Terminal Preview settings from Terminal settings #12907
Conversation
Preview gets existing settings from Release build
Utilized Invoke-CodeFormat from Code Health Script advice
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.
Okay, I think this is pretty straightforward. I'd ✅, but I'm a little curious about how this works unpackaged, esp with Preview branding, so I want a second opinion.
parentDirectoryForSettingsFile /= ReleaseSettingsFolder; | ||
|
||
if (!IsPackaged()) | ||
{ | ||
parentDirectoryForSettingsFile /= UnpackagedSettingsFolderName; | ||
} |
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 this is right for unpackaged versions of the Terminal. I might want to tap in @DHowett for this bit, hes a bit more familiar with running the Terminal unpackaged.
Just looking at my own files, I've only got a %localAppData%\Microsoft\Windows Terminal
.
Heck, I'm not sure this is ever relevant for Preview builds running unpackaged - I think they always just use %localAppData%\Microsoft\Windows Terminal
anyways. I might be wrong here.
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 -- preview builds just use the same storage as stable when they run unpackaged, so there's no worry here :)
bool releaseSettingExists = false; | ||
if (firstTimeSetup) | ||
{ | ||
#if defined(WT_BRANDING_PREVIEW) |
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.
Clever, simple, easy to parse what's happening. 👍
(sorry for the delays in reviewing 😅) |
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 believe this change is fine. With unpackaged WT, I don't believe we make a distinction for the settings path between Preview and non-Preview.
So, for unpackaged "preview" branded builds, it'll just happen to work anyways? Like, this is never an issue, unpackaged terminal just always works this way. Even if you ran an unpackaged Preview build first, with no existing settings, it would never find the "release" settings, because it would look in the nonsense path Okay I suppose I'm fine with this, but I might follow up with a cleanup PR with comments to that effect. |
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 noted. Thanks!
@msftbot make sure @DHowett signs off on this |
Hello @carlos-zamora! 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". |
Hey @DHowett review this so this can be in 1.15. |
parentDirectoryForSettingsFile /= ReleaseSettingsFolder; | ||
|
||
if (!IsPackaged()) | ||
{ | ||
parentDirectoryForSettingsFile /= UnpackagedSettingsFolderName; | ||
} |
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 -- preview builds just use the same storage as stable when they run unpackaged, so there's no worry here :)
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.
Thank you for doing this! Sorry I let it sit so long!
🎉 Handy links: |
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.
function (request, socket, head) { }
Windows Terminal Preview gets existing settings from Release build if
Preview settings are empty
This ensures that when settings are empty or not existent, we check if
we're currently in a preview build and if we are, we attempt to grab
settings from the Release build's setting path instead. We tested it
manually by changing settings in Release build and confirming that
changes migrated to Preview when settings are empty or not existent.
Additionally, we tested that settings.json of the running build changed.
We also ran existing TAEF testing locally and it passed.
In LoadAll() function in
src\cascadia\TerminalSettingsModel\CascadiaSettingsSerialization.cpp, we
first checked if the settings file us empty/exists via settingsString.
If it does not and we are in the Preview build, we try loading the
Release build's settings. We created modified versions of
CascadiaSettings::_settingsPath() and GetBaseSettingsPath() to get the
path for the Release build's settings. If the Release build settings do
exist and firstTimeSetup is true, we set it to settingsString so it can
be written to disk via WriteSettingsToDisk(). Note that currently we
hardcode the path of the Release build. This pull request was worked on
with @Dannihu01.
Validation Steps Performed Test1: Setting to firstTimeSetup is true
and loading settings.json from WT release when release exists -> Result:
settings.json AND GUI reflected WT release’s settings
Test2: Setting to firstTimeSetup is true and loading settings.json from
WT release when release doesn’t exist -> Result: settings.json AND GUI
reflected DEFAULT settings
Test3: (After running Test1) Setting to firstTimeSetup is false and
seeing if current settings.json matches WT release. (See if it doesn’t
change) -> Result: settings.json AND GUI reflected WT release’s settings
Closes #6855
Co-authored-by: Danniell Hu dannihu@umich.edu