-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into dev/migrie/s/1032-elevation-qol
- Loading branch information
Showing
755 changed files
with
122,456 additions
and
1,178 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,99 @@ | ||
--- | ||
author: Dustin Howett @DHowett | ||
created on: 2020-10-19 | ||
last updated: 2020-11-18 | ||
issue id: #8324 | ||
--- | ||
|
||
# Application State (in the Terminal Settings Model) | ||
|
||
## Abstract | ||
|
||
Terminal is going to need a place to store application "state", including: | ||
* Dialogs the user has chosen to hide with a `[ ] Do not ask again` checkbox, as proposed in [issue 6641] | ||
* Which dynamic profiles have been generated, as a way to resolve [user dissatisfaction] around profiles "coming back" | ||
* On-screen position of the window, active session state, layout, etc. for [eventual restoration] | ||
|
||
This specification provides for a place to store these things. | ||
|
||
## Inspiration | ||
|
||
Many other applications store cross-session state somewhere. | ||
|
||
## Solution Design | ||
|
||
It is the author's opinion that the above-mentioned settings are inappropriate for storage in the user's settings.json; | ||
they do not need to be propagated immediately to other instances of Windows Terminal, they are not intended to be | ||
edited, and storing them outside of settings.json defers the risk inherent in patching the user's settings file. | ||
|
||
Therefore, this document proposes that a separate application state archive (`state.json`) be stored next to | ||
`settings.json`. | ||
|
||
It would be accessed by way of an API hosted in the `Microsoft.Terminal.Settings` namespace. | ||
|
||
```idl | ||
namespace Microsoft.Terminal.Settings { | ||
[default_interface] | ||
runtimeclass ApplicationState { | ||
// GetForCurrentApplication will return an object deserialized from state.json. | ||
static ApplicationState GetForCurrentApplication(); | ||
void Clear(); | ||
IVector<guid> GeneratedProfiles; | ||
Boolean ShowCloseOnExitWarning; | ||
// ... further settings ... | ||
} | ||
} | ||
``` | ||
|
||
> 📝 The sole motivation for exposing this from Microsoft.Terminal.Settings is to concentrate JSON de-/serialization in one | ||
place. | ||
|
||
Of note: there is no explicit `Save` or `Commit` mechanism. Changes to the application state are committed durably a | ||
short duration after they're made. | ||
|
||
## UI/UX Design | ||
|
||
This has no direct impact on the UI/UX; however, we may want to add a button to general settings page titled "reset all | ||
dialogs" or "don't not ask me again about those things that, some time ago, I told you to not ask me about". | ||
|
||
We do not intend this file to be edited by hand, so it does not have to be user-friendly or serialized with indentation. | ||
|
||
## Capabilities | ||
|
||
### Accessibility | ||
|
||
It is not expected that this proposal will impact accessibility. | ||
|
||
### Security | ||
|
||
It is not expected that this proposal will impact security, as it uses our _existing_ JSON parser in a new place. | ||
|
||
### Reliability | ||
|
||
[comment]: # Will the proposed change improve reliability? If not, why make the change? | ||
|
||
The comment in this section heavily suggests that we should only make changes that improve reliability, not ones that | ||
maintain it. | ||
|
||
### Compatibility | ||
|
||
Some users who were expecting profiles to keep coming back after they delete them will need to adjust their behavior. | ||
|
||
### Performance, Power, and Efficiency | ||
|
||
## Potential Issues | ||
|
||
Another file on disk is another file users might edit. We'll need to throw out the entire application state payload if | ||
it's been damaged, instead of trying to salvage it, so that we more often "do the right thing." | ||
|
||
## Future considerations | ||
|
||
This will allow us to implement a number of the features mentioned at the head of this document. | ||
|
||
## Resources | ||
|
||
[issue 6641]: https://github.com/microsoft/terminal/issues/6641 | ||
[user dissatisfaction]: https://github.com/microsoft/terminal/issues/3231 | ||
[eventual restoration]: https://github.com/microsoft/terminal/issues/961 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
--- | ||
author: <first-name> <last-name> <github-id>/<email> | ||
created on: <yyyy-mm-dd> | ||
last updated: <yyyy-mm-dd> | ||
issue id: <github issue id> | ||
--- | ||
|
||
[comment]: # Use this template for proposing a new setting, or new values for an existing setting | ||
|
||
# Spec Title | ||
|
||
## Abstract | ||
|
||
[comment]: # Outline what this spec describes. | ||
|
||
## Background | ||
|
||
### Inspiration | ||
|
||
[comment]: # Are there existing precedents for this type of configuration? These may be in the Terminal, or in other applications | ||
|
||
### User Stories | ||
|
||
[comment]: # List off the use cases where two users might want a feature to have different behavior based on user preference. Include links to issues that might be relevant. | ||
|
||
### Future Considerations | ||
|
||
[comment]: # Are there other future features planned that might affect the current design of this setting? The team can help with this section during the review. | ||
|
||
## Solution Design | ||
|
||
[comment]: # Add notes that might be relevant to the proposed solutions. | ||
|
||
[comment]: # Also, outline various different proposed designs for this setting. These won't all be winners, but may help during the decision making process. For each proposed design: | ||
|
||
### Proposal 1: <name of proposal> | ||
|
||
[comment]: # Describe the values for the properties, how it'll be exposed in both JSON and the Settings UI, and list pros and cons for this design. If there are technical details for this proposal, include them here. | ||
|
||
* **Pros**: | ||
* **Cons**: | ||
|
||
## Conclusion | ||
|
||
[comment]: # Of the above proposals, which should we decide on, and why? | ||
|
||
|
||
## UI/UX Design | ||
|
||
[comment]: # How will different values of this setting affect the end user? | ||
|
||
## Potential Issues | ||
|
||
<table> | ||
|
||
<tr> | ||
<td><strong>Compatibility</strong></td> | ||
<td> | ||
|
||
[comment]: # Will the proposed change break existing code/behaviors? If so, how, and is the breaking change "worth it"? | ||
|
||
</td> | ||
</tr> | ||
</table> | ||
|
||
[comment]: # If there are any other potential issues, make sure to include them here. | ||
|
||
|
||
## Resources | ||
|
||
[comment]: # Be sure to add links to references, resources, footnotes, etc. | ||
|
||
|
||
### Footnotes | ||
|
||
<a name="footnote-1"><a>[1]: |
Oops, something went wrong.
This comment was marked as outdated.
Sorry, something went wrong.