Activity

1. Carlos Zamora (carlos-zamora)

   added

   Issue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.

   Product-TerminalThe new Windows Terminal.The new Windows Terminal.

   Priority-1A description (P1)A description (P1)

   Area-SettingsUIAnything specific to the SUIAnything specific to the SUI

   on Jan 12, 2021
2. Carlos Zamora (carlos-zamora)

   added this to the Terminal v1.6 milestone on Jan 12, 2021
3. ghost added

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Jan 12, 2021
4. Carlos Zamora (carlos-zamora)

   removed

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Jan 12, 2021
5. Carlos Zamora (carlos-zamora)

   self-assigned this

   on Jan 14, 2021
6. carlos-zamora commented on Jan 14, 2021

   

   Carlos Zamora (carlos-zamora)

   on Jan 14, 2021

   Author

   More actions

   So, I'm conflicted. There's the "brute-force" approach and the "elegant" way to do this:

   • brute-force approach:
     • When rename is accepted, iterate over all profiles and if profile.ColorSchemeName() == oldName, update the profile w/ profile.ColorSchemeName(newName).
   • elegant approach:
     • Idea: use ColorScheme references so that renaming a ColorScheme automatically updates whoever references it
     • Implementation:
       • ProfileViewModel holds a reference to a ColorScheme object (the one that the String ColorSchemeName refers to)
       • (the hard/annoying part) Since ColorScheme.Name() is not observable, we need to create a ColorSchemeViewModel to wrap each ColorScheme, which makes Name observable.
       • On a NameChanged event, ProfileViewModel would update Profile.ColorSchemeName
     • Concerns:
       • As I was writing this, I realized that that won't work either. We're creating the ProfileViewModel as we're navigating to the profile page. So the reference to the ColorScheme object would be created after the rename operation was completed.
       • To get around that issue, we would have to wrap all of the settings model objects with their respective view model objects when the Settings UI is opened.

   Dustin L. Howett (@DHowett) I'm going with the brute-force approach right now. Not too happy with it but it'll at least fix the bug for now. We should discuss what the overall architecture should look like, then file an issue to perform the refactor.
7. ghost added

   In-PRThis issue has a related PRThis issue has a related PR

   on Jan 14, 2021
8. ghost closed this as completedin #8793on Jan 22, 2021
9. ghost removed

   In-PRThis issue has a related PRThis issue has a related PR

   on Jan 22, 2021
10. ghost added

    Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.Fix is checked in, but it might be 3-4 weeks until a release.

    on Jan 22, 2021
11. ghost added a commit that references this issue on Jan 22, 2021

    Bugfix: sync color scheme rename with profile reference (#8793)

    ...

    This issue will close once commit 9700598 is merged into the 'main' branch.

    9700598
12. MPela (mpela81)

    added a commit that references this issue on Jan 28, 2021

    Bugfix: sync color scheme rename with profile reference (microsoft#8793)

    ...

    This issue will close once commit 9a53096 is merged into the 'main' branch.

    9a53096