Add initial settings UI spec #6720

cinnamon-msft · 2020-06-29T23:45:03Z

Summary of the Pull Request

This is the spec for the overall functionality of the settings UI - #1564.

There are proposals for the launch method and editing and saving settings that we should discuss.

References

PR Checklist

Closes #xxx
CLA signed. If not, go over here and sign the CLA
Tests added/passed
Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
Schema updated.
I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

spec.md

design.md

Validation Steps Performed

carlos-zamora

I'd like to see a bit more detail regarding the specific pages and like a storyboard for the experience. We don't need "booleans are checkboxes" level of detail, but a rough mockup of each page should suffice.

I think we also need to think about some of the other features that came in recently or are coming in soon. Specifically, I'm thinking about these:

Pointer Bindings (you and I can chat about this offline for the vision I have there)
Command palette commands
XAML Theming (PR)
New Tab Menu Customization (PR)
Really, just Command Palette is the big one. All of the other ones we could probably wait a bit for the specs to settle?

Also, it'd be neat if we could include links to the docs somewhere. Idk how often or where, but just a small callout for "each page will have a link to the docs" or something like that should be fine.

doc/specs/#1564 - Settings UI/spec.md

carlos-zamora · 2020-06-30T16:57:22Z

doc/specs/#1564 - Settings UI/spec.md

+- Globals
+- Profiles
+- Color schemes
+- Key bindings


For the Key bindings page:

Where does Command Palette customization come in? In the JSON, we're overriding the keybindings key with bindings. Should that be replicated here by replacing the "Key bindings" navigation item with "Bindings"? Is that intuitive?

Also, where will pointer bindings go in?

How do we record/represent the default and user-defined keybindings?

In my opinion, not everything needs to be exposed with the UI, at least not by default. Consider themes - these might be impossible to configure with the UI, so let's leave it as an exemplary case of "doesn't use the UI".

I'd think that at first, the command palette also isn't in the UI. There might be harder edge cases for editing commands with a UI, so lets just assume that we're not getting to it by v2.0.

In the future, I'd imagine that "Keybindings", "Commands", "Mouse Bindings" are all separate top-level settings pages, despite all being stored in the bindings. From the user's perspective, they're all separate entities, despite all being named the same thing.

doc/specs/#1564 - Settings UI/spec.md

carlos-zamora · 2020-06-30T18:19:33Z

doc/specs/#1564 - Settings UI/spec.md

+#### Proposal 2 - Implement a save button
+
+Users will only see their settings changes take place once they click "Save". Clicking "Save" will write to the settings.json file. This aligns with the functionality that exists today by editing the settings.json file in a text editor and saving it.


I think I prefer this? Should we have a "reset" button and a "reset to defaults button" too?

We could preview the changes as you make them in the open Terminal, then "save" actually applies them to the JSON file?

Maybe it should not be "Save" but "Apply Changes"?

doc/specs/#1564 - Settings UI/spec.md

zadjii-msft

I suppose provide feedback early and often. I'm not sure this is all my thoughts on the subject, but this certainly is some of them

zadjii-msft · 2020-07-09T13:23:36Z

doc/specs/#1564 - Settings UI/spec.md

+
+### Top-level navigation
+
+#### Proposal 1 - Align with JSON


I really hate this proposal, and love "Proposal 2 - More descriptive navigation". Let's expose the setting to the user in a more user-friendly rather than exposing how the code works.

+1 Proposal 2 seems more intuitive. Let's go with that one.

zadjii-msft · 2020-07-09T13:24:57Z

doc/specs/#1564 - Settings UI/spec.md

+    - Add new
+- Keyboard
+- Mouse*
+- Command Palette


I'm really okay with the UI for the command palette settings not being in Terminal 2.0 - it might have more edge cases than we're prepared to deal with in the rest of this cycle.

I want Command Palette SUI for Terminal v2. But I'm ok with that being something we add in like a month or 2 after Command Palette is widely available and finished.

The main concern is adding nested and iterable commands right? We could even just design/implement the Command Palette SUI without that, then add those two in later?

zadjii-msft · 2020-07-09T16:03:28Z

doc/specs/#1564 - Settings UI/spec.md

+
+#### Proposal 1 - Automatically save settings
+
+As users edit fields in the settings UI, they are automatically saved and written to the JSON file. This allows the user to see their settings changes taking place in real time.


I'm not sure how I feel about this. I typically prefer a conscious "save" button. Think of something like the Settings app on Windows - it doesn't really provide any feedback when you change a setting, even though it auto-saves changes. As a user, I often worry that the settings app didn't actually change the values, because there's no feedback that the value I changed was persisted.

That being said, auto-saving is convenient. I think there just needs to be some sort of _subtle_visual cue that the settings were saved when the user makes changes.

I'm just going to aside that it's generally bad to get too far away from the OS default behaviors, so if Windows 10 is auto-saving settings, apps designed for Windows 10 should follow suit or convince MS to go back to the Apply/OK paradigm.

My opinion: I liked the Apply/Cancel/Okay button since you can easily revert back if you don't like something.

I think there should be an auto-save option. However, there should also be manual option such as Chips has mentioned. So basically how you save the settings should be an option in settings. That can go under a General or Maintenance Page at the very bottom that's used for directly configuring how you want the Settings UI to look and feel as well how it does things like saving.

zadjii-msft · 2020-07-09T16:43:35Z

doc/specs/#1564 - Settings UI/spec.md

+#### Proposal 2 - Launch in a new tab
+
+Clicking the settings button in the dropdown menu will open the settings UI in a new tab. This helps us take steps toward supporting non-terminal content in a tab. However, tab tear-off should be implemented before we have this. This way, users can still see their changes take effect if they want by tearing out the settings UI.
+


opinion - I think I prefer 1 to 2 as far as launching goes. In my head, there was a third "switch the TerminalPage for a SettingsPage" option, where the entire contents of the window were changed into the settings UI until the user dismissed the settings. That certainly doesn't let the user preview the settings as well, and might be technically very challenging (esp with the titlebar shennanigans we currently have.)

zadjii-msft · 2020-07-09T16:45:39Z

doc/specs/#1564 - Settings UI/spec.md

+
+This does not affect performance, power, nor efficiency.
+
+## Potential Issues


Do we have any concerns about the way any of the current settings we have will be exposed to the user? Like, are there any where we're worried about what control we use to let the user change the setting?

Keybindings and commands (CmdPlt) are gonna be the weird ones, but Kayla and I have been thinking about them for a while now so you'll get those mockups in the upcoming commits 😉

I think Enum flags might be a bit weird to represent. But we don't really have any settings out right now that use enum flags, so we'll probably just deal with them when the Settings UI XAML is actually being implemented.

zadjii-msft · 2020-07-09T16:48:25Z

doc/specs/#1564 - Settings UI/spec.md

+Users will only see their settings changes take place once they click "Save". Clicking "Save" will write to the settings.json file. This aligns with the functionality that exists today by editing the settings.json file in a text editor and saving it.
+
+A future option could be adding a TerminalControl inside the settings UI to preview what the changes will look like before actually saving them to the settings.json file.
+


Should we discuss at all the technical details of how the settings are saved? Mention something about trying to make minimal updates to the user's settings file whenever possible?

This might be more dev-spec'y, but I'm thinking also about things like deleting profiles. For user-defined profiles, we can just remove them from the json, easy. But for something like the default profiles and dynamic ones, we need to mark them as hidden.

Just spoke with Kayla. I can handle that side of things and spec out the technical details, but add it to this PR. That way everything is all in one spot.

I'll probably start with this next week, after we have our design review meeting on Friday.

carlos-zamora · 2020-07-09T17:11:36Z

doc/specs/#1564 - Settings UI/spec.md

+
+Some users don't want a UI for the settings. We can update the `openSettings` key binding with a `settingsUI` option.
+
+If people still like the UI but want to access the JSON file, we can provide an "Open the JSON file" button at the bottom of the navigation menu.


Minor thing but it should be mentioned/discussed. How do you open defaults.json from the Settings UI instead of settings.json?

Is this something we want? I'm imagining a "reset to defaults" button, which I can add to this spec.

Not reset to defaults. Open the defaults.json. Right now, people alt-click "Settings" in the dropdown to open defaults.json. We've seen a ton of cases where people don't actually know that's a thing. Would it be possible to put 2 buttons in the Nav menu?...

Open the JSON file

Open the Defaults JSON file

(name could use some massaging but you get the idea)

carlos-zamora · 2020-07-09T17:15:56Z

doc/specs/#1564 - Settings UI/spec.md

+
+### Top-level navigation
+
+#### Proposal 1 - Align with JSON


+1 Proposal 2 seems more intuitive. Let's go with that one.

carlos-zamora · 2020-07-09T17:23:10Z

doc/specs/#1564 - Settings UI/spec.md

+- Tabs
+- Profiles
+    - Defaults
+    - Enumerate profiles


When we enumerate the profiles, how are "hidden" profiles handled? Do they still appear in the dropdown, but when you open it, there's a "hidden" switch? Or is there a way we can denote it as hidden in the dropdown (I think that would be the most ideal)?

So, because of how we serialize "hidden", if a user hides a profile, the only way to un-hide it is to go to the json?

carlos-zamora · 2020-07-09T17:32:07Z

doc/specs/#1564 - Settings UI/spec.md

+    - Add new
+- Keyboard
+- Mouse*
+- Command Palette


I want Command Palette SUI for Terminal v2. But I'm ok with that being something we add in like a month or 2 after Command Palette is widely available and finished.

The main concern is adding nested and iterable commands right? We could even just design/implement the Command Palette SUI without that, then add those two in later?

carlos-zamora · 2020-07-09T17:46:24Z

doc/specs/#1564 - Settings UI/spec.md

+
+This does not affect performance, power, nor efficiency.
+
+## Potential Issues


Keybindings and commands (CmdPlt) are gonna be the weird ones, but Kayla and I have been thinking about them for a while now so you'll get those mockups in the upcoming commits 😉

I think Enum flags might be a bit weird to represent. But we don't really have any settings out right now that use enum flags, so we'll probably just deal with them when the Settings UI XAML is actually being implemented.

carlos-zamora · 2020-07-09T17:49:37Z

doc/specs/#1564 - Settings UI/spec.md

+Users will only see their settings changes take place once they click "Save". Clicking "Save" will write to the settings.json file. This aligns with the functionality that exists today by editing the settings.json file in a text editor and saving it.
+
+A future option could be adding a TerminalControl inside the settings UI to preview what the changes will look like before actually saving them to the settings.json file.
+


Just spoke with Kayla. I can handle that side of things and spec out the technical details, but add it to this PR. That way everything is all in one spot.

I'll probably start with this next week, after we have our design review meeting on Friday.

miniksa · 2020-07-10T22:23:00Z

Friday Spec Brownbag Quick Summary

Today we had a meeting about this spec. Here's some quick notes of how the discussion went.
Attended: @DHowett, @cinnamon-msft, @leonMSFT, @carlos-zamora, @zadjii-msft, @miniksa

Launch Methods

Unanimous "launch inside the tab", not a new window
Matches other tabbed things like browsers
New window will naturally come when we solve tab tear-off
Launching settings another time will just activate the existing tab

Preview Window in Appearance Page

Unanimous yes. Do this. TermControl with a new connection that isn't real, just filled with some dummy sample text like what people might use (emojis, powerline fun, text tables, colors, etc.)

Editing/Saving

Automatic saving: No. We don't want to thrash the JSON file. If we had an in-memory model struct... maybe. Or if we were using a tear-off window, maybe.
OK, Cancel, Apply and/or a "Save" button and a "Preview Now" button. No. Gross. Old. Maybe temporarily during the prototype so the person doing the prototype only has to write two event handlers. But no. The preview window should be automagic on changes. The actual JSON should be written on Save button
Save button. Yes. Do this. Prevents JSON thrashing. We will have a little preview window anyway.

Navigation

Align with JSON: Ehhhhh. We could be more robust.
More description navigation: Yes, do this. Unanimous.
- "General General" is weird. We should find something else for that. General > Basic, General > (categories, like "Launch", "Rendering", "Interactivity", etc.)
  - We need a rocket ship icon for "Launch"
- It's ok to have few items on a page/category. Looked at some other ideas like how Visual Studio and some other Terminals like iTerm, xterm, etc. do it.

Keyboard Bindings

A listview sort of thing - Carlos and Kayla seemed more on board with this one up front.
A grid sort of thing - Michael, Mike, Dustin seemed more on board with this one up front.

(I didn't catch which one Leon was up with)

We don't think we have a readily available grid control
Lots of comparison to iTerm, xterm, and other terminals to see what they do
Examples given of other software that tends to do keybindings in a grid style
Discussion on whether we should have some sort of modal dialog when adding a binding that lets people press a key-combo to make it instead of typing it out
Discussion on combo/text boxes for the commands to be mapped
Discussion on what to do with commands that have arguments
- Commands with arguments that are already stringable by the command palette (e.g. new tab 1, new tab 2) are offered as drop down items
- Commands with arguments that are complex could be presented with a ... in the grid on the edge that launches a modal with the raw JSON to be edited
  - Perhaps place the schema describing how to write conforming arguments/bindings on the left and have a text editor or JSON editor on the right
  - Validate schema on close, stitch the JSON fragment back in
  - In the future, can migrate some of the ...s to launch a more robust editor based on the situation of the type of command, but default will allow raw editing if there is no specialty editor
For the listview, specifically discussing how we can show the arguments or have some sort of embedded arguments editing below it
Concern with both of them about amount of whitespace/compactness and good use
Concern with how to display/present the commands that people might not know about (easily buried in a dropdown/combo)
Any way to tree/hierarchy/group the similar commands together?

TobiasSekan · 2020-07-17T07:03:19Z

Hello,

The text box like

Background image
Command line
Font face
Font weight
GUID
Icon
Launch position
Name
Padding
Starting directory
Tab title
Word delimiters

should have a info sign ? with a tool-tip about the accepted input format.

Chips1234 · 2020-07-17T16:23:39Z

should have a info sign ? with a tool-tip about the accepted input format.
Yeah, or a window with help information.

carlos-zamora · 2020-07-17T16:36:03Z

Hello,

The text box like

Background image

Command line

Font face

Font weight

GUID

Icon

Launch position

Name

Padding

Starting directory

Tab title

Word delimiters

should have a info sign ? with a tool-tip about the accepted input format.

Ideally, we'd have validation through the Settings UI too or instead.

I'm realizing that through the Settings UI, you don't have to escape characters. So you can't just copy/paste some text from the JSON.

doc/specs/#1564 - Settings UI/spec.md

carlos-zamora · 2020-07-17T16:36:12Z

doc/specs/#1564 - Settings UI/spec.md

+
+## Appendix 1
+
+Below is the list of all settings on their respective pages in the settings UI. The title row aligns with the navigation view on the left of the UI. Bolded headers in those columns align with top nav on the page.


Anything with a path should also have a "browse" option:

Background image

Command line

Icon

Starting directory

Here's a doc that might help with that?

carlos-zamora · 2020-07-17T16:37:43Z

doc/specs/#1564 - Settings UI/spec.md

+- Tabs
+- Profiles
+    - Defaults
+    - Enumerate profiles


So, because of how we serialize "hidden", if a user hides a profile, the only way to un-hide it is to go to the json?

jtippet · 2020-07-23T20:03:22Z

My humble feedback:

Avoid having 2 pages with similar titles or icons. For example, there's two different "Global" pages. There's two usages of the word "Appearance". There's an icon of a mouse and another icon of a mouse cursor. It will cause confusion when someone says "I'm on the Global page, but I still don't see it".
General > Launch: there are 2 separate controls for width + height, but one control for X + Y position. Be consistent. Having separate controls for X + Y is going to be easier to code up and easier for accessibility to represent.
General > Launch: X + Y position don't have units. I guess I assume pixels, but physical pixels or relative pixels? I'd consider using % of screen as the unit, so the setting can meaningfully roam and/or be robust when you change screen resolution (e.g., project on a monitor).
General > Launch: "Disable dynamic profiles" is a negative checkbox, which makes it difficult to work out the logic. Invert it to "Enable dynamic profiles" so it's easier to understand. Also, it's not at all clear what "dynamic profiles" are without going to the documentation. I suggest instead "[X] Automatically create new profiles when new shells are installed"
General > Launch: Task manager and Settings > Apps use the term "Startup". MSG advises against "Launch".
General > Rendering: assuming "Windows resize behavior" is snapToGridOnResize, I would have put that under Interaction, since it doesn't affect rendering
Appearance > Global: "Hide close all tabs popup": maybe there should be a more scalable solution for suppressing warning dialogs, since there's also a "giant paste" warning dialog that people might want to suppress, and likely more in the future.
Profiles > Enumerate profiles: I can't imagine why anyone would want to look at the GUID of a profile? If there's a reason to show it, at least shuffle it off to the Advanced page.
Profiles > Enumerate profiles: I suggest adding a readonly edit box that demos the command line to launch directly to that profile. "Launch using wt -profile {guid}". Maybe even a button to create a start menu pin that launches that profile?
Profiles > Appearance: The Cursor Shape radio buttons in the mockup are difficult to visually scan. May I suggest putting the glyph before the text label, so everything can be scanned in equal vertical columns?
Profiles: it's not quite clear to me from the mockups how to revert a setting to the default (global?). For example, if I click "Enable acrylic" on a profile, is that profile's acrylic setting permanently forked from the global setting?

Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>

Chips1234 · 2020-07-26T00:47:12Z

Maybe we should have the title bar only extend to the side of the navbar and have the navigation bar extend to the top? And we should also have an acrylic (transparent) navbar.

samtholiya · 2020-07-31T01:56:31Z

@Chips1234 The view with title bar looks ugly i mean look at the settings app of windows it is a beauty because of acrylic navigation and no title bar. It has a settings app title but on the acrylic nav bar

Chips1234 · 2020-07-31T01:58:07Z

@Chips1234 The view with title bar looks ugly i mean look at the settings app of windows it is a beauty because of acrylic navigation and no title bar. It has a settings app title but on the acrylic nav bar

Yes, agreed.

Chips1234

Extend the navbar all the way to the top and maybe have it acrylic.

zadjii-msft

You know what, I'm looking through these designs and I dig it. I'm cool with this spec as-is, and I think the big contentious things (like general page layout, autosave or not, and in-window or pop-up window) are all answered.

Let's ship this and figure the rest out in post 🚀

leonMSFT

🚢

quangkieu · 2020-08-22T18:51:50Z

On the setting topic, I wonder if we could have setting json open in a new tab? Simular how vscode have both text and gui versions

DHowett · 2020-08-22T18:53:00Z

@quangkieu that only works because VSCode is also a text editor... which terminal is not 😄

quangkieu · 2020-08-27T01:47:32Z

@DHowett What I mean to suggest is if we have "Open JSON File" in this pull request #7370 to open a new panel that only have an editable text area box of the JSON content with save button. We would only check for JSON validation before save as full Setting validation would be check on read anyway. The "Open JSON File" would have a small > arrow button next to it for open external program. This request is mostly for quick edit like name of profile as I have default JSON open in Visual Studio and that is huge load time.

This commit introduces a rough prototype of the Settings UI as the `TerminalSettingsEditor`. This project was added to OpenConsole.sln and deploys as a standalone app. Some databinding is configured to a fake TerminalSettingsModel (located in the ObjectModel folder). This commit will start the settings UI feature branch, which will receive a full review on merge-back into main. References #6720 - Settings UI Spec and Design References #1564 - Settings UI Feature/Epic

This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>

This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in microsoft#6720, microsoft#8269 Follow-up work in microsoft#6800 Closes microsoft#1564 Closes microsoft#8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>

upload first draft of settings UI spec

53242c7

cinnamon-msft requested a review from a team June 29, 2020 23:45

ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jun 30, 2020

carlos-zamora requested changes Jun 30, 2020

View reviewed changes

ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jun 30, 2020

cinnamon-msft added 3 commits July 6, 2020 16:02

Merge branch 'master' into cinnamon/spec-settings-ui

b414852

update mockup and remove json setting

edfd673

add another nav option

f289008

WSLUser mentioned this pull request Jul 9, 2020

Allow users to create a 'collection' of tabs that will open specified command lines with different starting directories. #6851

Closed

zadjii-msft reviewed Jul 9, 2020

View reviewed changes

carlos-zamora reviewed Jul 9, 2020

View reviewed changes

DHowett mentioned this pull request Jul 12, 2020

FontSize not working #6884

Closed

cinnamon-msft added 6 commits July 13, 2020 13:51

Merge branch 'master' into cinnamon/spec-settings-ui

70d76b2

update from discussion on Friday

de97933

update navigation image

47698e6

add design doc

ae30dc9

make the spelling bot stop yelling at me

3b6701f

spell bot pls

2f31826

carlos-zamora reviewed Jul 17, 2020

View reviewed changes

cinnamon-msft and others added 2 commits July 24, 2020 12:04

add keyboard mockups

2eecb22

Update doc/specs/#1564 - Settings UI/spec.md

79e2b25

Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>

Chips1234 suggested changes Jul 31, 2020

View reviewed changes

carlos-zamora removed their assignment Aug 10, 2020

address feedback

53e305c

cinnamon-msft assigned carlos-zamora Aug 11, 2020

carlos-zamora approved these changes Aug 11, 2020

View reviewed changes

carlos-zamora removed their assignment Aug 11, 2020

zadjii-msft approved these changes Aug 19, 2020

View reviewed changes

zadjii-msft removed their assignment Aug 19, 2020

DHowett mentioned this pull request Aug 20, 2020

#1841 not good enough #7355

Closed

leonMSFT approved these changes Aug 21, 2020

View reviewed changes

carlos-zamora mentioned this pull request Aug 22, 2020

Add a Settings UI Prototype #7370

Merged

cinnamon-msft mentioned this pull request Sep 4, 2020

Feature Request - Implement Settings UI #1564

Closed

34 tasks

carlos-zamora unassigned DHowett, miniksa and leonMSFT Sep 9, 2020

carlos-zamora merged commit 1c7ee65 into master Sep 9, 2020

carlos-zamora deleted the cinnamon/spec-settings-ui branch September 9, 2020 23:11

carlos-zamora mentioned this pull request Dec 3, 2020

Implement the Settings UI #8048

Merged

carlos-zamora mentioned this pull request Dec 11, 2020

Epic: Settings UI Completion #6800

Open

25 tasks

		#### Proposal 2 - Implement a save button

		Users will only see their settings changes take place once they click "Save". Clicking "Save" will write to the settings.json file. This aligns with the functionality that exists today by editing the settings.json file in a text editor and saving it.


		#### Proposal 1 - Automatically save settings

		As users edit fields in the settings UI, they are automatically saved and written to the JSON file. This allows the user to see their settings changes taking place in real time.

		#### Proposal 2 - Launch in a new tab

		Clicking the settings button in the dropdown menu will open the settings UI in a new tab. This helps us take steps toward supporting non-terminal content in a tab. However, tab tear-off should be implemented before we have this. This way, users can still see their changes take effect if they want by tearing out the settings UI.


		This does not affect performance, power, nor efficiency.

		## Potential Issues

		Users will only see their settings changes take place once they click "Save". Clicking "Save" will write to the settings.json file. This aligns with the functionality that exists today by editing the settings.json file in a text editor and saving it.

		A future option could be adding a TerminalControl inside the settings UI to preview what the changes will look like before actually saving them to the settings.json file.


		Some users don't want a UI for the settings. We can update the `openSettings` key binding with a `settingsUI` option.

		If people still like the UI but want to access the JSON file, we can provide an "Open the JSON file" button at the bottom of the navigation menu.


		## Appendix 1

		Below is the list of all settings on their respective pages in the settings UI. The title row aligns with the navigation view on the left of the UI. Bolded headers in those columns align with top nav on the page.

Add initial settings UI spec #6720

Add initial settings UI spec #6720

Conversation

cinnamon-msft commented Jun 29, 2020 • edited by zadjii-msft Loading

Summary of the Pull Request

References

PR Checklist

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

carlos-zamora left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zadjii-msft left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carlos-zamora Jul 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miniksa commented Jul 10, 2020

Friday Spec Brownbag Quick Summary

Launch Methods

Preview Window in Appearance Page

Editing/Saving

Navigation

Keyboard Bindings

TobiasSekan commented Jul 17, 2020

Chips1234 commented Jul 17, 2020

carlos-zamora commented Jul 17, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jtippet commented Jul 23, 2020

Chips1234 commented Jul 26, 2020

samtholiya commented Jul 31, 2020

Chips1234 commented Jul 31, 2020

Chips1234 left a comment

Choose a reason for hiding this comment

zadjii-msft left a comment

Choose a reason for hiding this comment

leonMSFT left a comment

Choose a reason for hiding this comment

quangkieu commented Aug 22, 2020

DHowett commented Aug 22, 2020

quangkieu commented Aug 27, 2020

cinnamon-msft commented Jun 29, 2020 •

edited by zadjii-msft

Loading

carlos-zamora Jul 10, 2020 •

edited

Loading