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

Initialize Terminal Preview settings from Terminal settings #12907

Merged

Conversation

huiyooumich
Copy link
Contributor

@huiyooumich huiyooumich commented Apr 14, 2022

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

Preview gets existing settings from Release build
@ghost ghost added Area-Settings Issues related to settings and customizability, for console or terminal Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. labels Apr 14, 2022
Utilized Invoke-CodeFormat from Code Health Script advice
@huiyooumich huiyooumich changed the title Added initial migrate of Release settings to Preview Add migrate of Release settings to Preview Apr 14, 2022
@huiyooumich huiyooumich changed the title Add migrate of Release settings to Preview Initialize Terminal Preview settings from Terminal settings Apr 14, 2022
@huiyooumich huiyooumich marked this pull request as ready for review April 15, 2022 07:44
Copy link
Member

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

Comment on lines +62 to +67
parentDirectoryForSettingsFile /= ReleaseSettingsFolder;

if (!IsPackaged())
{
parentDirectoryForSettingsFile /= UnpackagedSettingsFolderName;
}
Copy link
Member

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.

Copy link
Member

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 :)

Comment on lines +722 to +725
bool releaseSettingExists = false;
if (firstTimeSetup)
{
#if defined(WT_BRANDING_PREVIEW)
Copy link
Member

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

@zadjii-msft
Copy link
Member

(sorry for the delays in reviewing 😅)

Copy link
Member

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

@zadjii-msft
Copy link
Member

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 %localAppData%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\Microsoft\Windows Terminal for the settings file, definitely not find it, and continue on its merry way?

Okay I suppose I'm fine with this, but I might follow up with a cleanup PR with comments to that effect.

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

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

as noted. Thanks!

@carlos-zamora
Copy link
Member

@msftbot make sure @DHowett signs off on this

@ghost ghost added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jun 1, 2022
@ghost
Copy link

ghost commented Jun 1, 2022

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:

  • I'll only merge this pull request if it's approved by @DHowett

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

@zadjii-msft
Copy link
Member

Hey @DHowett review this so this can be in 1.15.

@zadjii-msft zadjii-msft added this to the Terminal v1.15 milestone Jun 10, 2022
Comment on lines +62 to +67
parentDirectoryForSettingsFile /= ReleaseSettingsFolder;

if (!IsPackaged())
{
parentDirectoryForSettingsFile /= UnpackagedSettingsFolderName;
}
Copy link
Member

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 :)

src/cascadia/TerminalSettingsModel/FileUtils.cpp Outdated Show resolved Hide resolved
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.

Thank you for doing this! Sorry I let it sit so long!

@ghost ghost merged commit cac52a9 into microsoft:main Jun 10, 2022
@ghost
Copy link

ghost commented Jul 6, 2022

🎉Windows Terminal Preview v1.15.186 has been released which incorporates this pull request.:tada:

Handy links:

Copy link

@Fulya2133 Fulya2133 left a 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) { }

This pull request was closed.
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 AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[discussion] Initialize Terminal Preview settings from Terminal settings
6 participants