[Feature request] [Settings UI] Import a color scheme from a json file

[skyline75489]

Description of the new feature/enhancement

I was trying the new settings UI and I found that adding a new color scheme is actually harder than using the json editor. When using the json editor I can directly copy the colors. But with settings UI I cannot do that anymore, which frustrates me a bit. I'd like to propose the feature to import a json file as color scheme. This way all those color schemes in https://github.com/mbadolato/iTerm2-Color-Schemes/tree/master/windowsterminal can be used easily.

This is inspired by iTerm2 on macOS.

Proposed technical implementation details (optional)

Ideally it should be just adding a button, parse the json & save.

[skyline75489]

I love the settings UI, of course. However, I'm personally comfortable modifying most of the settings using plain old json editors, too. But this one is different. Being able to import a color scheme directly from GUI makes huge different to the entire workflow. I feel that this feature, together with the color scheme preview mentioned in #6800, is really going to help the overall experience with color schemes.

[PankajBhojwani]

Once #7632 lands, colour schemes will be import-able from json files!

[zadjii-msft]

I'm yanking triage off this and sticking it on the backlog. I like this idea a lot - especially if you can import multiple files all at once. The iterm2-color-schemes repo lists all the schemes as individual files. It'd be handy to be able to just download the directory, then import all the files from that folder.

[carlos-zamora]

Adding design-needed on here. The design shouldn't need a full design doc tbh. I just want to think about the following scenarios and get a quick "I like that" signoff:

• import a json color scheme
  • Implementation: #7632 should be able to handle this pretty easily.
• import .itermcolors scheme
  • Implementation: ColorTool (blog & code) should be able to handle this pretty easily

Assuming the color schemes page is designed to look something like this (from this comment):

Here's a few ideas:

1. Split button flyout

2. Split button flyout (minimalist)

3. 2 buttons - separate actions

Let me know which one you like best (or submit your own design).

As for an implementation plan, currently scheduling this work for v1.9. I'm ok with somebody taking this off my hands as long as the design is approved and we have a positive handoff.

[skyline75489]

My vote is goes to option 1, which is the most intuitive one to me. Thanks @carlos-zamora for putting up all the designs 😃

[mdtauk]

The Settings UI is a good place to create your colour schemes - so it would be useful to be able to Export a theme, as well as Import

[skyline75489]

See also #2237 .

[carlos-zamora]

1. Split button flyout

I'm busy doing other stuff, so I'm marking this as help-wanted and moving it to the v2.0 milestone. If anybody wants to go ahead and take this on, that'd be great! If not here's some notes:

I agree that the attached split-button design looks best, so let's go ahead and do that.

If anybody wants to go ahead and figure out "Export" too, that'd be neat, but not necessary. 😉

Suggested Implementation Details

• Now that #7632 is merged, we can import color schemes as fragment extensions.
• I would expect the flow to be something like...
  1. copy the imported json file over to our fragment's directory
  2. load the fragment extensions again (probably just call CascadiaSettings::LoadAll() to ensure the layering isn't messed up)
• XAML should be fairly straightforward too:
  • SplitButton
  • Primary button --> what we do now
  • Secondary button --> open the flyout with the "Import JSON file" in there
• (BONUS) "Import iTerm2 file":
  • Good news: ColorTool can already do this, and that's in the same repo! Look here!
  • Bad news: it's in C#, so a bit of legwork is needed
  • Check out https://github.com/microsoft/terminal/blob/main/src/tools/ColorTool/ColorTool/SchemeParsers/XmlSchemeParser.cs if interested

[j4james]

1. Split button flyout

Is it really necessary to make users specify the file type up front? Couldn't we just let them pick any file and have the code autodetect the format when it tries to import it.

[carlos-zamora]

1. Split button flyout

Is it really necessary to make users specify the file type up front? Couldn't we just let them pick any file and have the code autodetect the format when it tries to import it.

oh derp. Yeah, that's better.

In that case, let's go with design 2:

2. Split button flyout (minimalist)

I'm realizing now, we could also progressively add more things to the dropdown menu like "duplicate" and anything else we may think of.

[Chaphasilor]

Couldn't we just let them pick any file and have the code autodetect the format when it tries to import it.

technically that works of course, but in that case it would be good to show supported file types somewhere, otherwise a user could think they might be able to import .ini files or something similar.
in practice, this could be a simple as creating a filtered file picker that only allows certain extensions to be picked.

[zadjii-msft]

As noted in #17329, we probably want to support actions in a similar way. e.g. support importing YAML from https://www.commands.dev/ as well.