Renaming a color scheme used by a profile should properly update the profile

[carlos-zamora]

Steps to reproduce

1. Open Settings UI
2. Have a profile ("Profile A") refer to a custom color scheme ("Color Scheme A")
3. Go to the Color Schemes page
4. Select "Color Scheme A"
5. Rename it to something else ("Color Scheme B")
6. Navigate back to the profile that referred to this color scheme ("Profile A")

Expected behavior

"Profile A" should now reference "Color Scheme B".

Actual behavior

"Profile A" refers to "Campbell"

Additional details

The TerminalSettingsModel stores Profile.ColorScheme as a string reference to the name of the ColorScheme.
In TerminalSettingsEditor (Profiles.cpp), if a ColorScheme with that name isn't found, we fallback to "Campbell".

Perhaps a better architecture would be to reference a ColorScheme object in the TerminalSettingsModel? Or at least reference a ColorScheme object in the ViewModel in TerminalSettingsEditor.

[carlos-zamora]

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.

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