Feature: Application State #8324
Assignees
Labels
Area-Settings
Issues related to settings and customizability, for console or terminal
Issue-Feature
Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Needs-Tag-Fix
Doesn't match tag requirements
Product-Terminal
The new Windows Terminal.
Milestone
Comments
DHowett
added
Area-Settings
ghost
added
the
Needs-Triage
6 tasks
DHowett
removed
the
Needs-Triage
DHowett
added a commit
that referenced
this issue
Dec 4, 2020
This commit introduces a specification for "cross-session" app state that isn't stored in the user's settings.json. Specs #8324
zadjii-msft
added
Issue-Feature
2 tasks
lhecker
added a commit
that referenced
this issue
Jun 30, 2021
This commit introduces a basic ApplicationState class, without being used for anything yet to aid reviewers. At a later point actual usages of this new class may be added separately. ## References This commit is an initial step towards implementing #8324. ## PR Checklist * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Creating a `state.json` with `{"generatedProfiles":["{53e75ed9-2b63-4118-856d-0510c4f6b97e}"]}` updates the ApplicationState, as observed through a debugger ✔️ * Deleting the "generatedProfiles" field sets the corresponding field back to nullopt ✔️
3 tasks
ghost
pushed a commit
that referenced
this issue
Aug 16, 2021
Let's say a user doesn't know that they need to write `"hidden": true` in order to prevent a profile from showing up (and a settings UI doesn't exist). Naturally they would open settings.json and try to remove the profile object. This section of code recognizes if a profile was seen before and marks it as `"hidden": true` by default and thus ensures the behavior the user expects: Profiles won't show up again after they've been removed from settings.json. ## References #8324 - Application State ## PR Checklist * [x] Closes #8270 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * settings.json/state.json are created if they don't exist ✔️ * Removing any profile from settings.json doesn't cause it to appear again ✔️ * Hitting save in SUI creates profiles with `"hidden": true` ✔️ * Removing a default profile and hitting save in SUI works ❌ An empty object is added instead.
DHowett
pushed a commit
that referenced
this issue
Aug 25, 2021
Let's say a user doesn't know that they need to write `"hidden": true` in order to prevent a profile from showing up (and a settings UI doesn't exist). Naturally they would open settings.json and try to remove the profile object. This section of code recognizes if a profile was seen before and marks it as `"hidden": true` by default and thus ensures the behavior the user expects: Profiles won't show up again after they've been removed from settings.json. ## References #8324 - Application State ## PR Checklist * [x] Closes #8270 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * settings.json/state.json are created if they don't exist ✔️ * Removing any profile from settings.json doesn't cause it to appear again ✔️ * Hitting save in SUI creates profiles with `"hidden": true` ✔️ * Removing a default profile and hitting save in SUI works ❌ An empty object is added instead.
ghost
pushed a commit
that referenced
this issue
Sep 8, 2021
This commit adds initial support for saving window layout on application close. Done: - Add user setting for if tabs should be maintained. - Added events to track the number of open windows for the monarch, and then save if you are the last window closing. - Saves layout when the user explicitly hits the "Close Window" button. - If the user manually closed all of their tabs (through the tab x button or through closing all panes on the tab) then remove any saved state. - Saves in the ApplicationState file a list of actions the terminal can perform to restore its layout and the window size/position information. - This saves an action to focus the correct pane, but this won't actually work without #10978. Note that if you have a pane zoomed, it does still zoom the correct pane, but when you unzoom it will have a different pane selected. Todo: - multiple windows? Right now it can only handle loading/saving one window. - PR #11083 will save multiple windows. - This also sometimes runs into the existing bug where multiple tabs appear to be focused on opening. Next Steps: - The business logic of when the save is triggered can be adjusted as necessary. - Right now I am taking the pragmatic approach and just saving the state as an array of objects, but only ever populate it with 1, that way saving multiple windows in the future could be added without breaking schema compatibility. Selfishly I'm hoping that handling multiple windows could be spun off into another pr/feature for now. - One possible thing that can maybe be done is that the commandline can be augmented with a "--saved ##" attribute that would load from the nth saved state if it exists. e.g. if there are 3 saved windows, on first load it can spawn three wt --saved {0,1,2} that would reopen the windows? This way there also exists a way to load a copy of a previous window (if it is in the saved state). - Is the application state something that is planned to be public/user editable? In theory the user could since it is just json, but I don't know what it buys them over just modifying their settings and startupActions. Validation Steps Performed: - The happy path: open terminal -> set setting to true -> close terminal -> reopen and see tabs. Tested with powershell/cmd/wsl windows. - That closing all panes/tabs on their own will remove the saved session. - Open multiple windows, close windows and confirm that the last window closed saves its state. The generated file stores a sequence of actions that will be executed to restore the terminal to its saved form. References #8324 This is also one of the items on #5000 Closes #766
|
@DHowett I have half a mind to close this out since 4/5 of the original ideas are all added now. This issue feels like it was tracking just "add the infrastructure to do this". Do you think we need to leave this open to track follow ups (like other megathreads)? |
|
Nah, let's kill it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Terminal is going to need a place to store application "state", including:
[ ] Do not ask againcheckbox, as proposed in Add a "remember my decision" checkbox to our confirmation dialogs #6641exit codemessage the first time it happens.The text was updated successfully, but these errors were encountered: