terminal/src/cascadia/TerminalSettingsEditor/Launch.cpp

77 lines
2.9 KiB
C++
Raw Normal View History

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "Launch.h"
#include "Launch.g.cpp"
#include "LaunchPageNavigationState.g.cpp"
#include "EnumEntry.h"
using namespace winrt::Windows::UI::Xaml::Navigation;
using namespace winrt::Windows::Foundation;
using namespace winrt::Microsoft::Terminal::Settings::Model;
namespace winrt::Microsoft::Terminal::Settings::Editor::implementation
{
Launch::Launch()
{
InitializeComponent();
Persist window layout on window close (#10972) 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 microsoft/terminal#5000 Closes #766
2021-09-09 00:44:53 +02:00
INITIALIZE_BINDABLE_ENUM_SETTING(FirstWindowPreference, FirstWindowPreference, FirstWindowPreference, L"Globals_FirstWindowPreference", L"Content");
INITIALIZE_BINDABLE_ENUM_SETTING(LaunchMode, LaunchMode, LaunchMode, L"Globals_LaunchMode", L"Content");
INITIALIZE_BINDABLE_ENUM_SETTING(WindowingBehavior, WindowingMode, WindowingMode, L"Globals_WindowingBehavior", L"Content");
// BODGY
// Xaml code generator for x:Bind to this will fail to find UnloadObject() on Launch class.
// To work around, check it ourselves on construction and FindName to force load.
// It's specified as x:Load=false in the XAML. So it only loads if this passes.
if (CascadiaSettings::IsDefaultTerminalAvailable())
{
FindName(L"DefaultTerminalDropdown");
}
}
void Launch::OnNavigatedTo(const NavigationEventArgs& e)
{
_State = e.Parameter().as<Editor::LaunchPageNavigationState>();
}
IInspectable Launch::CurrentDefaultProfile()
{
const auto defaultProfileGuid{ _State.Settings().GlobalSettings().DefaultProfile() };
return winrt::box_value(_State.Settings().FindProfile(defaultProfileGuid));
}
void Launch::CurrentDefaultProfile(const IInspectable& value)
{
const auto profile{ winrt::unbox_value<Model::Profile>(value) };
_State.Settings().GlobalSettings().DefaultProfile(profile.Guid());
}
Allow generated profiles to be deleted (#11007) Re-enables the delete button for generated profiles in the settings UI. Additionally fixes "Startup Profiles" to only list active profiles. Profiles are considered deleted if they're absent from settings.json, but their GUID has been encountered before. Or in other words, from a user's perspective: Generated profiles are added to the settings.json automatically only once. Thus if the user chooses to delete the profile (e.g. using the delete button) they aren't re-added automatically and thus appear to have been deleted. Meanwhile those generated profiles are actually only marked as "hidden" as well as "deleted", but still exist in internal profile lists. The "hidden" attribute hides them from all existing menus. The "deleted" one hides them from the settings UI and prevents them from being written to disk. It would've been preferrable of course to just not generate and add deleted profile to internal profile lists in the first place. But this would've required far more wide-reaching changes. The settings UI for instance requires a list of _all_ profiles in order to allow a user to re-create previously deleted profiles. Such an approach was attempted but discarded because of it's current complexity overhead. ## References * Part of #9997 * A sequel to 5d36e5d ## PR Checklist * [x] Closes #10960 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * "Startup Profiles" doesn't list deleted profiles ✔️ * Manually removing an item from settings.json removes the profile ✔️ * Removing cmd.exe and saving doesn't create empty objects (#10960) ✔️ * "Add a new profile" lists deleted profiles ✔️ * "Duplicate" recreates previously deleted profiles ✔️ * Profiles are always created with GUIDs ✔️
2021-08-24 00:00:08 +02:00
winrt::Windows::Foundation::Collections::IObservableVector<IInspectable> Launch::DefaultProfiles() const
{
const auto allProfiles = _State.Settings().AllProfiles();
std::vector<IInspectable> profiles;
profiles.reserve(allProfiles.Size());
// Remove profiles from the selection which have been explicitly deleted.
// We do want to show hidden profiles though, as they are just hidden
// from menus, but still work as the startup profile for instance.
for (const auto& profile : allProfiles)
{
if (!profile.Deleted())
{
profiles.emplace_back(profile);
}
}
return winrt::single_threaded_observable_vector(std::move(profiles));
}
Persist window layout on window close (#10972) 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 microsoft/terminal#5000 Closes #766
2021-09-09 00:44:53 +02:00
bool Launch::ShowFirstWindowPreference() const noexcept
{
return Feature_PersistedWindowLayout::IsEnabled();
}
}