-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
hidden
profiles are deleted, not hidden
#4139
Comments
A hidden profile also can't be started using the command line argument |
This comment has been minimized.
This comment has been minimized.
## Summary of the Pull Request This PR replaces `CascadiaSettings::_profiles` with... - `_allProfiles`: the list of all available profiles in the settings model (i.e. settings.json, dynamic profiles, etc...) - `_activeProfiles`: the list of all non-hidden profiles (used for the new tab dropdown) ## References #8018: maintaining a list of all profiles allows us to serialize hidden profiles #1564: Settings UI can link to `AllProfiles()` instead of `ActiveProfiles()` to expose hidden profiles ## PR Checklist * [x] Closes #4139 * [x] Tests added/passed ## Validation Steps Performed Deploy and testing succeeded
🎉This issue was addressed in #8070, which has now been successfully released as Handy links: |
Right now, "hiding" a profile totally deletes it. This has some interesting effects on profiles that are in active use - their icons and background images disappear, and their
closeOnExit
s get ignored. Anything that relies on the presence of a profile for a given tab fails.I'm wondering if
hidden
shouldn't just mean "don't show in the list". This has other interesting follow-on questions: should a profile that's been hidden still be launchable with a keyboard shortcut that specifically targets it? should a hidden profile be defaultable? I don't totally see why not.Partially related to [workitem for customizing the dropdown menu].
The text was updated successfully, but these errors were encountered: