-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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.
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
[SPEC] Add a lightweight spec for Portable Mode #15032
Conversation
|
||
_No change is expected._ | ||
|
||
## Potential Issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work with...
- dynamic profiles? Is it going to be an issue if a profile is added, but is invalid on another machine?
- fragment extensions? (basically the same question/answer as above, but figured I'd cover my bases)
"firstWindowPreference": "persistedWindowLayout"
? Specifically if we're pointing to a profile that doesn't exist anymore.- moving between a Windows 10 and Windows 11 machine? (I think this one you said you fixed, but I want to double check)
- any settings that are more "machine specific" rather than "terminal specific" (i.e.
"experimental.rendering.forceFullRepaint"
and"experimental.rendering.software"
) - the shell extension (and running
wt.exe
from Run)? Do we run the portable mode version? - state.json (ApplicationState.h)
I think most of these scenarios are handled just fine, I just want to double check. They might be worth mentioning in the spec too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- dynamic profiles are generated as normal; if the portable install is moved to somewhere where they don't apply, they will disappear
- fragment extensions are just another dynamic profile source; see above
- same thing that happens if you get rid of a dynamic profile in normal Terminal
- this is the same as upgrading a machine from windows 10 to 11 after installing Terminal
- "machine specific" settings still apply to the installation; we do not have (and should not have) a separate store for machine specific settings
- there is no shell extension registration in portable mode, but if we do it it is already set up to run wt from the same folder as the shell extension
- state is saved alongside settings, always.
This pull request implements portable mode for Windows Terminal, which will make side by side deployment of different versions generally more feasible. Portable mode was specified in #15032. There are three broad categories of changes in this PR: 1. Changes to settings loading. 2. A new indicator in the settings UI plus a link to the portable mode docs. 3. A new application display name, `Terminal (Portable)`, which users will hopefully include in their bug reports. It's surprisingly small for how big a deal it is! Related to #15034 Closes #1386
This pull request implements portable mode for Windows Terminal, which will make side by side deployment of different versions generally more feasible. Portable mode was specified in #15032. There are three broad categories of changes in this PR: 1. Changes to settings loading. 2. A new indicator in the settings UI plus a link to the portable mode docs. 3. A new application display name, `Terminal (Portable)`, which users will hopefully include in their bug reports. It's surprisingly small for how big a deal it is! Related to #15034 Closes #1386 (cherry picked from commit e6a3fa8) Service-Card-Id: 88719279 Service-Version: 1.17
Are there any plans to implement this in the near future? The ability to specify a custom (relative) path instead of a hardcoded I could take a stab at implementing this, if we agree on a specification. |
No description provided.