2020-12-11 22:34:21 +01:00
|
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
|
|
#include "Launch.g.h"
|
|
|
|
|
|
#include "LaunchPageNavigationState.g.h"
|
|
|
|
|
|
#include "Utils.h"
|
|
|
|
|
|
|
|
|
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Editor::implementation
|
|
|
|
|
|
{
|
|
|
|
|
|
struct LaunchPageNavigationState : LaunchPageNavigationStateT<LaunchPageNavigationState>
|
|
|
|
|
|
{
|
|
|
|
|
|
public:
|
|
|
|
|
|
LaunchPageNavigationState(const Model::CascadiaSettings& settings) :
|
|
|
|
|
|
_Settings{ settings } {}
|
|
|
|
|
|
|
2021-03-04 20:27:03 +01:00
|
|
|
|
WINRT_PROPERTY(Model::CascadiaSettings, Settings, nullptr)
|
2020-12-11 22:34:21 +01:00
|
|
|
|
};
|
|
|
|
|
|
|
Manually dismiss popups when the window moves, or the SUI scrolls (#10922)
## Summary of the Pull Request
BODGY!
This solution was suggested in https://github.com/microsoft/microsoft-ui-xaml/issues/4554#issuecomment-887815332.
When the window moves, or when a ScrollViewer scrolls, dismiss any popups that are visible. This happens automagically when an app is a real XAML app, but it doesn't work for XAML Islands.
## References
* upstream at https://github.com/microsoft/microsoft-ui-xaml/issues/4554
## PR Checklist
* [x] Closes #9320
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Unfortunately, we've got a bunch of scroll viewers in our SUI. So I did something bodgyx2 to make our life a little easier.
`DismissAllPopups` can be used to dismiss all popups for a particular UI element. However, we've got a bunch of pages with scroll viewers that may or may not have popups in them. Rather than define the same exact body for all their `ViewChanging` events, the `HasScrollViewer` struct will just do it for you!
Inside the `HasScrollViewer` stuct, we can't get at the `XamlRoot()` that our subclass implements. I mean, _we_ can, but when XAML does it's codegen, _XAML_ won't be able to figure it out.
Fortunately for us, we don't need to! The sender is a UIElement, so we can just get _their_ `XamlRoot()`.
So, you can fix this for any SUI page with just a simple
```diff
- <ScrollViewer>
+ <ScrollViewer ViewChanging="ViewChanging">
```
```diff
- struct AddProfile : AddProfileT<AddProfile>
+ struct AddProfile : public HasScrollViewer<AddProfile>, AddProfileT<AddProfile>
```
## Validation Steps Performed
* the window doesn't close when you move it
* the popups _do_ close when you move the window
* the popups close when you scroll any SUI page
2021-08-16 15:41:17 +02:00
|
|
|
|
struct Launch : public HasScrollViewer<Launch>, LaunchT<Launch>
|
2020-12-11 22:34:21 +01:00
|
|
|
|
{
|
|
|
|
|
|
public:
|
|
|
|
|
|
Launch();
|
|
|
|
|
|
|
|
|
|
|
|
void OnNavigatedTo(const winrt::Windows::UI::Xaml::Navigation::NavigationEventArgs& e);
|
|
|
|
|
|
|
|
|
|
|
|
IInspectable CurrentDefaultProfile();
|
|
|
|
|
|
void CurrentDefaultProfile(const IInspectable& value);
|
2021-08-24 00:00:08 +02:00
|
|
|
|
winrt::Windows::Foundation::Collections::IObservableVector<IInspectable> DefaultProfiles() const;
|
2020-12-11 22:34:21 +01:00
|
|
|
|
|
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 ShowFirstWindowPreference() const noexcept;
|
|
|
|
|
|
|
2021-03-04 20:27:03 +01:00
|
|
|
|
WINRT_PROPERTY(Editor::LaunchPageNavigationState, State, nullptr);
|
2020-12-11 22:34:21 +01:00
|
|
|
|
|
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
|
|
|
|
GETSET_BINDABLE_ENUM_SETTING(FirstWindowPreference, Model::FirstWindowPreference, State().Settings().GlobalSettings, FirstWindowPreference);
|
2020-12-11 22:34:21 +01:00
|
|
|
|
GETSET_BINDABLE_ENUM_SETTING(LaunchMode, Model::LaunchMode, State().Settings().GlobalSettings, LaunchMode);
|
2021-02-19 22:09:17 +01:00
|
|
|
|
GETSET_BINDABLE_ENUM_SETTING(WindowingBehavior, Model::WindowingMode, State().Settings().GlobalSettings, WindowingBehavior);
|
2020-12-11 22:34:21 +01:00
|
|
|
|
};
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Editor::factory_implementation
|
|
|
|
|
|
{
|
|
|
|
|
|
BASIC_FACTORY(Launch);
|
|
|
|
|
|
}
|
