author | created on | last updated | issue id |
---|---|---|---|
Dustin L. Howett @DHowett |
2023-03-22 |
2023-03-22 |
none |
Since we are planning on officially supporting unpackaged execution, I propose a special mode where Terminal stores its
settings in a settings
folder next to WindowsTerminal.exe
.
- PortableApps
- "Embeddable" Python, which relies on the deployment of a specific file to the Python root
- If running without package identity,
CascadiaSettings
will look for the presence of a file called.portable
next toMicrosoft.Terminal.Settings.Model.dll
. - If that file is present, it will change the settings and state paths to be rooted in a subfolder named
settings
next toMicrosoft.Terminal.Settings.Model.dll
.
Right now, the only thing that makes Terminal not work in a "portable" manner is that it saves settings to
%LOCALAPPDATA%
.
No UI/UX impact is expected.
- Distributors could ship a self-contained and preconfigured Terminal installation.
- Users could archive fully-working preconfigured versions of Terminal.
- Developers (such as those on the team) could easily test multiple versions of Terminal without worrying about global settings pollution.
No change is expected.
No change is expected.
More code always bears a risk.
This is a net new feature, and it does not break any existing features. A distributor (or a user) can opt in (or out) by
adding (or removing) the .portable
file.
The following features may be impacted.
- Dynamic Profiles and Fragment Extensions
- No impact expected. Dynamic profiles will still be generated. If a portable installation is moved to a machine without the dynamic profile source, that profile will disappear.
firstWindowPreference
andstate.json
- No impact expected.
- State is stored next to settings, even for portable installations.
- If a dynamic profile was saved in
state
and has been removed, Terminal will proceed as in non-portable mode.
- Moving an install from Windows 10 to Windows 11 and back
- No impact expected.
- "Machine-specific" settings, like those about rendering and repainting
- No impact expected.
- Terminal does not distinguish settings that are specific to a machine. These settings will move along with the portable install.
- The shell extension
- No impact expected.
- The shell extension will not be registered with Windows.
- If we choose to register the shell extension, it is already prepared for running a version of WT from the same directory. Registering the portable shell extension will make it launch portable Terminal.
No change is expected.
- User confusion around where settings are stored.
- In the future, perhaps
.portable
could itself contain a directory path into which we would store settings. - We could consider adding an indicator in the Settings UI.
- Because we are using the module path of the Settings Model DLL, a future unpackaged version of the shell extension that supports profile loading would read the right settings file (assuming it used the settings model.)
- If we choose to store the shell extension cache in the registry, we would need to avoid doing so in portable mode.