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.

Sign up for GitHub

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

Jump to bottom

Add support for profiles.defaults in defaults.json #5276

Closed
carlos-zamora opened this issue Apr 7, 2020 · 4 comments · Fixed by #11184
Closed

Add support for profiles.defaults in defaults.json #5276

carlos-zamora opened this issue Apr 7, 2020 · 4 comments · Fixed by #11184
Assignees
@carlos-zamora
Labels
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. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal v2.0

Comments

@carlos-zamora
Copy link
Member

Description of the new feature/enhancement

defaults.json only supports "profiles" as a list, not an object. This means that profiles.defaults cannot be used to present the default values for profiles.

Proposed technical implementation details (optional)

This is a surprisingly large change with very little gain. The CascadiaSettings::LoadAll() function must be rewritten to match the following order:

  1. load defaults/profiles.defaults = A
  2. load defaults/profiles.list = B
    • apply [A] to [B]
    • apply [B] to [B]
  3. load dynamics = C
    • apply [A] to [C]
  4. load user/profiles.defaults = D
    • apply [D] to all existing profiles [B, C]
  5. load user/profiles.list = E
    • apply [A] to [E]
    • apply [D] to [E]
    • apply [E] to [E]

Additionally, dynamic profiles add an additional level of complexity. Each dynamic profile generator relies on DefaultProfileUtils' CreateDefaultProfile. We need to layer defaults/profiles.defaults here. But defaults/profiles.defaults is saved in CascadiaSettings. So we need to find a way to ensure that a construction of a Profile object has defaults/profiles.defaults layers already.
@carlos-zamora carlos-zamora added Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. labels Apr 7, 2020
@ghost ghost added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Apr 7, 2020
@carlos-zamora carlos-zamora mentioned this issue Apr 7, 2020
Merged
2 tasks
@DHowett-MSFT
Copy link
Contributor

DHowett-MSFT commented Apr 8, 2020 •
edited
Loading

We may want to consider a "prototype Profile" object that we .Clone(). This simplifies the flow:

  1. Create a new Profile = Prototype
  2. layer defaults/profiles.defaults on [Prototype]
  3. load defaults/profiles.list
    • copy [Prototype] = B
    • layer list[i] on [B]
  4. load dynamics
    • copy [Prototype] = C
    • dynamic loader changes [C]
  5. layer user/profiles.defaults on [Prototype]
    • layer user defaults on all existing profiles [B, C]
  6. load user/profiles.list
    • copy [Prototype] = D
    • layer list[i] on [D]
(as something closer to pseudocode)
  1. Prototype = new Profile()
  2. Prototype.layer(defaults.json profiles.defaults)
  3. load defaults/profiles.list; for each:
    • B = Prototype.Clone()
    • B.layer(list[i])
  4. load dynamics
    • C = Prototype.Clone()
    • (dynamic loader applies changes to C)
  5. Prototype.layer(user.json profiles.defaults)
    • B.layer(user.json profiles.defaults) (apply to stock profiles)
    • C.layer(user.json profiles.defaults) (apply to dynamic profiles)
  6. load user/profiles.list; for each:
    • D = Prototype.Clone()
    • D.layer(list[i])

If you notice that 1-2 and 4-5 are the same operation, gold star. This will also reduce the difference between "defaults.json" and "settings.json".

@DHowett-MSFT DHowett-MSFT added Issue-Task It's a feature request, but it doesn't really need a major design. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. labels Apr 8, 2020
@DHowett-MSFT DHowett-MSFT added this to the Terminal v1.x milestone Apr 10, 2020
@DHowett-MSFT
Copy link
Contributor

Tagging into v1.x. We should figure out the settings model in advance of doing the settings UI.

@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Apr 10, 2020
@cinnamon-msft cinnamon-msft mentioned this issue Apr 10, 2020
Closed
34 tasks
@JustinGrote
Copy link

Related to this, defaults.json should have the "defaults" and "list" subformat as well by default. The more "OneOf" entries in the JSON schema that can be removed for the various configuration iterations that can be removed, the better for code generation tools like my MSTerminalSettings 2.0 powershell module.

@DHowett-MSFT
Copy link
Contributor

That's not exactly "related to" this issue insofar as it literally just is this issue. 😄
We just about did this for v1, but recognized that it would be too great a change for us to feel comfortable with ☹️

@carlos-zamora carlos-zamora self-assigned this May 12, 2020
@DHowett DHowett mentioned this issue Oct 11, 2020
Merged
@carlos-zamora carlos-zamora mentioned this issue Sep 10, 2021
Merged
4 tasks
@ghost ghost added the In-PR This issue has a related PR label Sep 14, 2021
@ghost ghost closed this as completed in #11184 Sep 22, 2021
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Sep 22, 2021
ghost pushed a commit that referenced this issue Sep 22, 2021
@lhecker
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184)
168d28b 
This commit reduces the code surface that interacts with raw JSON data,
reducing code complexity and improving maintainability.
Files that needed to be changed drastically were additionally
cleaned up to remove any code cruft that has accrued over time.

In order to facility this the following changes were made:
* Move JSON handling from `CascadiaSettings` into `SettingsLoader`
  This allows us to use STL containers for data model instances.
  For instance profiles are now added to a hashmap for O(1) lookup.
* JSON parsing within `SettingsLoader` doesn't differentiate between user,
  inbox and fragment JSON data, reducing code complexity and size.
  It also centralizes common concerns, like profile deduplication and
  ensuring that all profiles are assigned a GUID.
* Direct JSON modification, like the insertion of dynamic profiles into
  settings.json were removed. This vastly reduces code complexity,
  but unfortunately removes support for comments in JSON on first start.
* `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced
  with `FromJson`, allowing us to remove JSON-based color scheme validation.
* `Profile`s used to test their wish to layer using `ShouldBeLayered`, which
  was replaced with a GUID-based hashmap lookup on previously parsed profiles.

Further changes were made as improvements upon the previous changes:
* Compact the JSON files embedded binary, saving 28kB
* Prevent double-initialization of the color table in `ColorScheme`
* Making `til::color` getters `constexpr`, allow better optimizations

The result is a reduction of:
* 48kB binary size for the Settings.Model.dll
* 5-10% startup duration
* 26% code for the `CascadiaSettings` class
* 1% overall code in this project

Furthermore this results in the following breaking changes:
* The long deprecated "globals" settings object will not be detected and no
  warning will be created during load.
* The initial creation of a new settings.json will not produce helpful comments.

Both cases are caused by the removal of manual JSON handling and the
move to representing the settings file with model objects instead

## PR Checklist
* [x] Closes #5276
* [x] Closes #7421
* [x] I work here
* [x] Tests added/passed

## Validation Steps Performed

* Out-of-box-experience is identical to before ✔️
  (Except for the settings.json file lacking comments.)
* Existing user settings load correctly ✔️
* New WSL instances are added to user settings ✔️
* New fragments are added to user settings ✔️
* All profiles are assigned GUIDs ✔️
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@carlos-zamora carlos-zamora

Labels
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. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
Terminal v2.0
Development

Successfully merging a pull request may close this issue.

Reduce usage of Json::Value throughout Terminal.Settings.Model microsoft/terminal
4 participants
@carlos-zamora @DHowett-MSFT @JustinGrote @cinnamon-msft