terminal/src/cascadia/TerminalApp/TabManagement.cpp

1001 lines
38 KiB
C++
Raw Normal View History

minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
//
// This file contains much of the code related to tab management for the
// TerminalPage. Things like opening new tabs, selecting different tabs,
// switching tabs, should all be handled in this file. Hypothetically, in the
// future, the contents of this file could be moved to a separate class
// entirely.
//
#include "pch.h"
#include "TerminalPage.h"
#include "Utils.h"
#include "../../types/inc/utils.hpp"
#include <LibraryResources.h>
#include "TabRowControl.h"
#include "ColorHelper.h"
#include "DebugTapConnection.h"
#include "SettingsTab.h"
#include "..\TerminalSettingsModel\FileUtils.h"
#include <shlobj.h>
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
using namespace winrt;
using namespace winrt::Windows::Foundation::Collections;
using namespace winrt::Windows::UI::Xaml;
using namespace winrt::Windows::UI::Xaml::Controls;
using namespace winrt::Windows::UI::Core;
using namespace winrt::Windows::System;
using namespace winrt::Windows::ApplicationModel::DataTransfer;
using namespace winrt::Windows::UI::Text;
using namespace winrt::Windows::Storage;
using namespace winrt::Windows::Storage::Pickers;
using namespace winrt::Windows::Storage::Provider;
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
using namespace winrt::Microsoft::Terminal;
using namespace winrt::Microsoft::Terminal::Control;
using namespace winrt::Microsoft::Terminal::TerminalConnection;
using namespace winrt::Microsoft::Terminal::Settings::Model;
using namespace ::TerminalApp;
using namespace ::Microsoft::Console;
namespace winrt
{
namespace MUX = Microsoft::UI::Xaml;
namespace WUX = Windows::UI::Xaml;
using IInspectable = Windows::Foundation::IInspectable;
}
namespace winrt::TerminalApp::implementation
{
// Method Description:
// - Open a new tab. This will create the TerminalControl hosting the
// terminal, and add a new Tab to our list of tabs. The method can
// optionally be provided a NewTerminalArgs, which will be used to create
// a tab using the values in that object.
// Arguments:
// - newTerminalArgs: An object that may contain a blob of parameters to
// control which profile is created and with possible other
// configurations. See TerminalSettings::CreateWithNewTerminalArgs for more details.
// - existingConnection: An optional connection that is already established to a PTY
// for this tab to host instead of creating one.
// If not defined, the tab will create the connection.
HRESULT TerminalPage::_OpenNewTab(const NewTerminalArgs& newTerminalArgs, winrt::Microsoft::Terminal::TerminalConnection::ITerminalConnection existingConnection)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
try
{
const auto profile{ _settings.GetProfileForArgs(newTerminalArgs) };
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
const auto settings{ TerminalSettings::CreateWithNewTerminalArgs(_settings, newTerminalArgs, *_bindings) };
_CreateNewTabFromPane(_MakePane(newTerminalArgs, false, existingConnection));
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
const uint32_t tabCount = _tabs.Size();
const bool usedManualProfile = (newTerminalArgs != nullptr) &&
(newTerminalArgs.ProfileIndex() != nullptr ||
newTerminalArgs.Profile().empty());
// Lookup the name of the color scheme used by this profile.
const auto scheme = _settings.GetColorSchemeForProfile(profile);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// If they explicitly specified `null` as the scheme (indicating _no_ scheme), log
// that as the empty string.
const auto schemeName = scheme ? scheme.Name() : L"\0";
TraceLoggingWrite(
g_hTerminalAppProvider, // handle to TerminalApp tracelogging provider
"TabInformation",
TraceLoggingDescription("Event emitted upon new tab creation in TerminalApp"),
TraceLoggingUInt32(1u, "EventVer", "Version of this event"),
TraceLoggingUInt32(tabCount, "TabCount", "Count of tabs currently opened in TerminalApp"),
TraceLoggingBool(usedManualProfile, "ProfileSpecified", "Whether the new tab specified a profile explicitly"),
TraceLoggingGuid(profile.Guid(), "ProfileGuid", "The GUID of the profile spawned in the new tab"),
TraceLoggingBool(settings.DefaultSettings().UseAcrylic(), "UseAcrylic", "The acrylic preference from the settings"),
TraceLoggingFloat64(settings.DefaultSettings().Opacity(), "TintOpacity", "Opacity preference from the settings"),
TraceLoggingWideString(settings.DefaultSettings().FontFace().c_str(), "FontFace", "Font face chosen in the settings"),
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
TraceLoggingWideString(schemeName.data(), "SchemeName", "Color scheme set in the settings"),
TraceLoggingKeyword(MICROSOFT_KEYWORD_MEASURES),
TelemetryPrivacyDataTag(PDT_ProductAndServicePerformance));
return S_OK;
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
CATCH_RETURN();
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Method Description:
Move Pane to Tab (GH7075) (#10780) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
// - Sets up state, event handlers, etc on a tab object that was just made.
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Arguments:
Move Pane to Tab (GH7075) (#10780) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
// - newTabImpl: the uninitialized tab.
void TerminalPage::_InitializeTab(winrt::com_ptr<TerminalTab> newTabImpl)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
Move Pane to Tab (GH7075) (#10780) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
newTabImpl->Initialize();
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Add the new tab to the list of our tabs.
_tabs.Append(*newTabImpl);
_mruTabs.Append(*newTabImpl);
newTabImpl->SetDispatch(*_actionDispatch);
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
newTabImpl->SetActionMap(_settings.ActionMap());
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Give the tab its index in the _tabs vector so it can manage its own SwitchToTab command.
_UpdateTabIndices();
// Hookup our event handlers to the new terminal
Move Pane to Tab (GH7075) (#10780) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
_RegisterTabEvents(*newTabImpl);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Don't capture a strong ref to the tab. If the tab is removed as this
// is called, we don't really care anymore about handling the event.
auto weakTab = make_weak(newTabImpl);
// When the tab's active pane changes, we'll want to lookup a new icon
// for it. The Title change will be propagated upwards through the tab's
// PropertyChanged event handler.
newTabImpl->ActivePaneChanged([weakTab, weakThis{ get_weak() }]() {
auto page{ weakThis.get() };
auto tab{ weakTab.get() };
if (page && tab)
{
// Possibly update the icon of the tab.
page->_UpdateTabIcon(*tab);
Split `TermControl` into a Core, Interactivity, and Control layer (#9820) ## Summary of the Pull Request Brace yourselves, it's finally here. This PR does the dirty work of splitting the monolithic `TermControl` into three components. These components are: * `ControlCore`: This encapsulates the `Terminal` instance, the `DxEngine` and `Renderer`, and the `Connection`. This is intended to everything that someone might need to stand up a terminal instance in a control, but without any regard for how the UX works. * `ControlInteractivity`: This is a wrapper for the `ControlCore`, which holds the logic for things like double-click, right click copy/paste, selection, etc. This is intended to be a UI framework-independent abstraction. The methods this layer exposes can be called the same from both the WinUI TermControl and the WPF control. * `TermControl`: This is the UWP control. It's got a Core and Interactivity inside it, which it uses for the actual logic of the terminal itself. TermControl's main responsibility is now By splitting into smaller pieces, it will enable us to * write unit tests for the `Core` and `Interactivity` bits, which we desparately need * Combine `ControlCore` and `ControlInteractivity` in an out-of-proc core process in the future, to enable tab tearout. However, we're not doing that work quite yet. There's still lots of work to be done to enable that, thought this is likely the biggest portion. Ideally, this would just be methods moved wholesale from one file to another. Unfortunately, there are a bunch of cases where that didn't work as well as expected. Especially when trying to better enforce the boundary between the classes. We've got a couple tests here that I've added. These are partially examples, and partially things I ran into while implementing this. A bunch of things from #7001 can go in now that we have this. This PR is gonna be a huge pain to review - 38 files with 3,730 additions and 1,661 deletions is nothing to scoff at. It will also conflict 100% with anything that's targeting `TermControl`. I'm hoping we can review this over the course of the next week and just be done with it, and leave plenty of runway for 1.9 bugs in post. ## References * In pursuit of #1256 * Proc Model: #5000 * https://github.com/microsoft/terminal/projects/5 ## PR Checklist * [x] Closes #6842 * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760249 * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760258 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * I don't love the names `ControlCore` and `ControlInteractivity`. Open to other names. * I added a `ICoreState` interface for "properties that come from the `ControlCore`, but consumers of the `TermControl` need to know". In the future, these will all need to be handled specially, because they might involve an RPC call to retrieve the info from the core (or cache it) in the window process. * I've added more `EventArgs` to make more events proper `TypedEvent`s. * I've changed how the TerminalApp layer requests updated TaskbarProgress state. It doesn't need to pump TermControl to raise a new event anymore. * ~~Something that snuck into this branch in the very long history is the switch to `DCompositionCreateSurfaceHandle` for the `DxEngine`. @miniksa wrote this originally in 30b8335, I'm just finally committing it here. We'll need that in the future for the out-of-proc stuff.~~ * I reverted this in c113b65d9. We can revert _that_ commit when we want to come back to it. * I've changed the acrylic handler a decent amount. But added tests! * All the `ThrottledFunc` things are left in `TermControl`. Some might be able to move down into core/interactivity, but once we figure out how to use a different kind of Dispatcher (because a UI thread won't necessarily exist for those components). * I've undoubtably messed up the merging of the locking around the appearance config stuff recently ## Validation Steps Performed I've got a rolling list in https://github.com/microsoft/terminal/issues/6842#issuecomment-810990460 that I'm updating as I go.
2021-04-27 17:50:45 +02:00
// Update the taskbar progress as well. We'll raise our own
// SetTaskbarProgress event here, to get tell the hosting
// application to re-query this value from us.
page->_SetTaskbarProgressHandlers(*page, nullptr);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
});
// The RaiseVisualBell event has been bubbled up to here from the pane,
// the next part of the chain is bubbling up to app logic, which will
// forward it to app host.
newTabImpl->TabRaiseVisualBell([weakTab, weakThis{ get_weak() }]() {
auto page{ weakThis.get() };
auto tab{ weakTab.get() };
if (page && tab)
{
page->_RaiseVisualBellHandlers(nullptr, nullptr);
}
});
newTabImpl->DuplicateRequested([weakTab, weakThis{ get_weak() }]() {
auto page{ weakThis.get() };
auto tab{ weakTab.get() };
if (page && tab)
{
page->_DuplicateTab(*tab);
}
});
Add Split Tab option to tab context menu (#10832) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Adds the Split Tab option to the tab context menu. Clicking this option will `auto` split the active pane of the tab into a duplicate pane. Clicking on an unfocused tab and splitting it will bring that tab into focus and split its active pane. We could make this a flyout from the context menu to let people choose horizontal/vertical split in the future if it's requested. I'm also wondering if this should be called Split Pane instead of Split Tab? <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5025 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments https://user-images.githubusercontent.com/48369326/127691919-aae4683a-212a-4525-a0eb-a61c877461ed.mp4 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2021-08-05 15:46:24 +02:00
newTabImpl->SplitTabRequested([weakTab, weakThis{ get_weak() }]() {
auto page{ weakThis.get() };
auto tab{ weakTab.get() };
if (page && tab)
{
page->_SplitTab(*tab);
}
});
newTabImpl->ExportTabRequested([weakTab, weakThis{ get_weak() }]() {
auto page{ weakThis.get() };
auto tab{ weakTab.get() };
if (page && tab)
{
page->_ExportTab(*tab);
}
});
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
auto tabViewItem = newTabImpl->TabViewItem();
_tabView.TabItems().Append(tabViewItem);
// Set this tab's icon to the icon from the user's profile
if (const auto profile{ newTabImpl->GetFocusedProfile() })
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
if (!profile.Icon().empty())
Move Pane to Tab (GH7075) (#10780) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
{
newTabImpl->UpdateIcon(profile.Icon());
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
tabViewItem.PointerReleased({ this, &TerminalPage::_OnTabClick });
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// When the tab requests close, try to close it (prompt for approval, if required)
newTabImpl->CloseRequested([weakTab, weakThis{ get_weak() }](auto&& /*s*/, auto&& /*e*/) {
auto page{ weakThis.get() };
auto tab{ weakTab.get() };
if (page && tab)
{
page->_HandleCloseTabRequested(*tab);
}
});
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// When the tab is closed, remove it from our list of tabs.
newTabImpl->Closed([tabViewItem, weakThis{ get_weak() }](auto&& /*s*/, auto&& /*e*/) {
if (auto page{ weakThis.get() })
{
page->_RemoveOnCloseRoutine(tabViewItem, page);
}
});
// The tab might want us to toss focus into the control, especially when
// transient UIs (like the context menu, or the renamer) are dismissed.
newTabImpl->RequestFocusActiveControl([weakThis{ get_weak() }]() {
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
if (const auto page{ weakThis.get() })
{
page->_FocusCurrentTab(false);
}
});
Move Pane to Tab (GH7075) (#10780) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
// This kicks off TabView::SelectionChanged, in response to which
// we'll attach the terminal's Xaml control to the Xaml root.
_tabView.SelectedItem(tabViewItem);
}
// Method Description:
// - Create a new tab using a specified pane as the root.
// Arguments:
// - pane: The pane to use as the root.
void TerminalPage::_CreateNewTabFromPane(std::shared_ptr<Pane> pane)
{
auto newTabImpl = winrt::make_self<TerminalTab>(pane);
_InitializeTab(newTabImpl);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Method Description:
// - Get the icon of the currently focused terminal control, and set its
// tab's icon to that icon.
// Arguments:
// - tab: the Tab to update the title for.
void TerminalPage::_UpdateTabIcon(TerminalTab& tab)
{
if (const auto profile = tab.GetFocusedProfile())
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
tab.UpdateIcon(profile.Icon());
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
// Method Description:
// - Handle changes to the tab width set by the user
void TerminalPage::_UpdateTabWidthMode()
{
_tabView.TabWidthMode(_settings.GlobalSettings().TabWidthMode());
}
// Method Description:
// - Handle changes in tab layout.
void TerminalPage::_UpdateTabView()
{
// Never show the tab row when we're fullscreen. Otherwise:
// Show tabs when there's more than 1, or the user has chosen to always
// show the tab bar.
const bool isVisible = (!_isFullscreen && !_isInFocusMode) &&
(_settings.GlobalSettings().ShowTabsInTitlebar() ||
(_tabs.Size() > 1) ||
_settings.GlobalSettings().AlwaysShowTabs());
Make the window name `_quake` special (#9785) ## Summary of the Pull Request This PR adds some special behavior to the window named "\_quake". * When creating the quake window, it ignores "initialRows" and "initialCols" and opens on the top half of the monitor. - It uses `initialPosition` to determine which monitor this is * It cannot be moved * It can only be vertically resized on the bottom border. * It's always in focus mode. - We should probably have an issue tracking "Allow showing tabs in focus mode"? Maybe? - This one element is maybe the one I'm least attached to When renaming a window to "\_quake", it adopts all those behaviors as well. It does not exit focus mode when leaving QM, nor does it resize back. That seemed unnecessary. ## References * As spec'ed in #9274 * See also #8888 ## PR Checklist * [x] In the pursuit of #653 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated, but I'm not gonna do any of that till quake mode is totally done. ## Detailed Description of the Pull Request / Additional comments Note that this doesn't do things like: * dropdown * global hotkey summon * summon to the current monitor * summon to the current desktop I'm doing #653 _very_ piecemeal, to try and make the PRs less egregious. ## Validation Steps Performed * validated that center on launch still works * validated that QM works on different monitors based on `initialPosition` * validated entering/exiting QM behaves as expected ## TODO! * [ ] When snapping the quake window between desktops with <kbd>win+shift+arrow</kbd>, the window doesn't horizontally re-size to the new monitor dimensions. It should.
2021-04-26 21:36:23 +02:00
if (_tabView)
{
// collapse/show the tabs themselves
_tabView.Visibility(isVisible ? Visibility::Visible : Visibility::Collapsed);
}
if (_tabRow)
{
// collapse/show the row that the tabs are in.
// NaN is the special value XAML uses for "Auto" sizing.
_tabRow.Height(isVisible ? NAN : 0);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
// Method Description:
// - Duplicates the current focused tab
void TerminalPage::_DuplicateFocusedTab()
{
if (const auto terminalTab{ _GetFocusedTabImpl() })
{
_DuplicateTab(*terminalTab);
}
}
// Method Description:
// - Duplicates specified tab
// Arguments:
// - tab: tab to duplicate
void TerminalPage::_DuplicateTab(const TerminalTab& tab)
{
try
{
// TODO: GH#5047 - We're duplicating the whole profile, which might
// be a dangling reference to old settings.
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
//
// In the future, it may be preferable to just duplicate the
// current control's live settings (which will include changes
// made through VT).
_CreateNewTabFromPane(_MakePane(nullptr, true, nullptr));
const auto runtimeTabText{ tab.GetTabText() };
if (!runtimeTabText.empty())
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
if (auto newTab{ _GetFocusedTabImpl() })
{
newTab->SetTabText(runtimeTabText);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
CATCH_LOG();
}
Add Split Tab option to tab context menu (#10832) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Adds the Split Tab option to the tab context menu. Clicking this option will `auto` split the active pane of the tab into a duplicate pane. Clicking on an unfocused tab and splitting it will bring that tab into focus and split its active pane. We could make this a flyout from the context menu to let people choose horizontal/vertical split in the future if it's requested. I'm also wondering if this should be called Split Pane instead of Split Tab? <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5025 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments https://user-images.githubusercontent.com/48369326/127691919-aae4683a-212a-4525-a0eb-a61c877461ed.mp4 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2021-08-05 15:46:24 +02:00
// Method Description:
// - Sets the specified tab as the focused tab and splits its active pane
// Arguments:
// - tab: tab to split
void TerminalPage::_SplitTab(TerminalTab& tab)
{
try
{
_SetFocusedTab(tab);
_SplitPane(tab, SplitDirection::Automatic, 0.5f, _MakePane(nullptr, true));
Add Split Tab option to tab context menu (#10832) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Adds the Split Tab option to the tab context menu. Clicking this option will `auto` split the active pane of the tab into a duplicate pane. Clicking on an unfocused tab and splitting it will bring that tab into focus and split its active pane. We could make this a flyout from the context menu to let people choose horizontal/vertical split in the future if it's requested. I'm also wondering if this should be called Split Pane instead of Split Tab? <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5025 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments https://user-images.githubusercontent.com/48369326/127691919-aae4683a-212a-4525-a0eb-a61c877461ed.mp4 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2021-08-05 15:46:24 +02:00
}
CATCH_LOG();
}
// Method Description:
// - Exports the content of the Terminal Buffer inside the tab
// Arguments:
// - tab: tab to export
winrt::fire_and_forget TerminalPage::_ExportTab(const TerminalTab& tab)
{
// This will be used to set up the file picker "filter", to select .txt
// files by default.
static constexpr COMDLG_FILTERSPEC supportedFileTypes[] = {
{ L"Text Files (*.txt)", L"*.txt" },
{ L"All Files (*.*)", L"*.*" }
};
// An arbitrary GUID to associate with all instances of this
// dialog, so they all re-open in the same path as they were
// open before:
static constexpr winrt::guid clientGuidExportFile{ 0xF6AF20BB, 0x0800, 0x48E6, { 0xB0, 0x17, 0xA1, 0x4C, 0xD8, 0x73, 0xDD, 0x58 } };
try
{
if (const auto control{ tab.GetActiveTerminalControl() })
{
// GH#11356 - we can't use the UWP apis for writing the file,
// because they don't work elevated (shocker) So just use the
// shell32 file picker manually.
auto path = co_await SaveFilePicker(*_hostingHwnd, [control](auto&& dialog) {
THROW_IF_FAILED(dialog->SetClientGuid(clientGuidExportFile));
try
{
// Default to the Downloads folder
auto folderShellItem{ winrt::capture<IShellItem>(&SHGetKnownFolderItem, FOLDERID_Downloads, KF_FLAG_DEFAULT, nullptr) };
dialog->SetDefaultFolder(folderShellItem.get());
}
CATCH_LOG(); // non-fatal
THROW_IF_FAILED(dialog->SetFileTypes(ARRAYSIZE(supportedFileTypes), supportedFileTypes));
THROW_IF_FAILED(dialog->SetFileTypeIndex(1)); // the array is 1-indexed
THROW_IF_FAILED(dialog->SetDefaultExtension(L"txt"));
// Default to using the tab title as the file name
THROW_IF_FAILED(dialog->SetFileName((control.Title() + L".txt").c_str()));
});
if (!path.empty())
{
const auto buffer = control.ReadEntireBuffer();
CascadiaSettings::ExportFile(path, buffer);
}
}
}
CATCH_LOG();
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Method Description:
// - Removes the tab (both TerminalControl and XAML) after prompting for approval
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Arguments:
// - tab: the tab to remove
winrt::Windows::Foundation::IAsyncAction TerminalPage::_HandleCloseTabRequested(winrt::TerminalApp::TabBase tab)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
if (tab.ReadOnly())
{
ContentDialogResult warningResult = co_await _ShowCloseReadOnlyDialog();
// If the user didn't explicitly click on close tab - leave
if (warningResult != ContentDialogResult::Primary)
{
co_return;
}
}
_RemoveTab(tab);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Method Description:
// - Removes the tab (both TerminalControl and XAML)
// Arguments:
// - tab: the tab to remove
void TerminalPage::_RemoveTab(const winrt::TerminalApp::TabBase& tab)
{
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
uint32_t tabIndex{};
if (!_tabs.IndexOf(tab, tabIndex))
{
// The tab is already removed
return;
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
// We use _removing flag to suppress _OnTabSelectionChanged events
// that might get triggered while removing
_removing = true;
auto unsetRemoving = wil::scope_exit([&]() noexcept { _removing = false; });
const auto focusedTabIndex{ _GetFocusedTabIndex() };
// Removing the tab from the collection should destroy its control and disconnect its connection,
// but it doesn't always do so. The UI tree may still be holding the control and preventing its destruction.
tab.Shutdown();
uint32_t mruIndex{};
if (_mruTabs.IndexOf(tab, mruIndex))
{
_mruTabs.RemoveAt(mruIndex);
}
_tabs.RemoveAt(tabIndex);
_tabView.TabItems().RemoveAt(tabIndex);
_UpdateTabIndices();
// To close the window here, we need to close the hosting window.
if (_tabs.Size() == 0)
{
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
// If we are supposed to save state, make sure we clear it out
// if the user manually closed all tabs.
Persist window layout cont. save multiple windows (#11083) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Continuation of https://github.com/microsoft/terminal/pull/10972 to handle multiple windows, requires that to be merged first. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Also closes #766 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Rough changelog: Normally saving is triggered to occur every 30s, or sooner if a window is created/closed. The existing behavior of saving on last close is maintained to bypass that throttling. The automatic saving allows for crash recovery. Additionally all window layouts will be saved upon taking the `quit` action. For loading we will check if we are the first window, that there are any saved layouts, and if the setting is enabled, and then depending on if we were given command line args or startup actions. - create a new window for each saved layout, or - take the first layout for our self and then a new window for each other layout. This also saves the layout when the quit action is taken. Misc changes - A -s,--saved argument was added to the command line to facilitate opening all of the windows with the right settings. This also means that while a terminal session is running you can do wt -s idx to open a copy of window idx. There isn't a stable ordering of which idx each window gets saved as (it is whatever the iteration order of _peasants is), so it is just a cute hack for now. - All position calculation has been moved up to AppHost this does mean we need to awkwardly pass around positions in a couple of unexpected places, but no solution was perfect. - Renamed "Open tabs from a previous session" to "Open windows from a previous session". (not reflected in video below) - Now save runtime tab color and window names - Only enabled for non-elevated windows - Add some change tracking to ApplicationState <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ![output](https://user-images.githubusercontent.com/6185249/131163473-d649d204-a589-41ad-b9d9-c4c0528cb684.gif)
2021-09-27 23:18:39 +02:00
// Do this only if we are the last window; the monarch will notice
// we are missing and remove us that way otherwise.
if (!_maintainStateOnTabClose && ShouldUsePersistedLayout(_settings) && _numOpenWindows == 1)
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
{
auto state = ApplicationState::SharedInstance();
state.PersistedWindowLayouts(nullptr);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
_LastTabClosedHandlers(*this, nullptr);
}
else if (focusedTabIndex.has_value() && focusedTabIndex.value() == gsl::narrow_cast<uint32_t>(tabIndex))
{
// Manually select the new tab to get focus, rather than relying on TabView since:
// 1. We want to customize this behavior (e.g., use MRU logic)
// 2. In fullscreen (GH#5799) and focus (GH#7916) modes the _OnTabItemsChanged is not fired
// 3. When rearranging tabs (GH#7916) _OnTabItemsChanged is suppressed
const auto tabSwitchMode = _settings.GlobalSettings().TabSwitcherMode();
if (tabSwitchMode == TabSwitcherMode::MostRecentlyUsed)
{
const auto newSelectedTab = _mruTabs.GetAt(0);
_UpdatedSelectedTab(newSelectedTab);
_tabView.SelectedItem(newSelectedTab.TabViewItem());
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
else
{
// We can't use
// auto selectedIndex = _tabView.SelectedIndex();
// Because this will always return -1 in this scenario unfortunately.
//
// So, what we're going to try to do is move the focus to the tab
// to the left, within the bounds of how many tabs we have.
//
// EX: we have 4 tabs: [A, B, C, D]. If we close:
// * A (tabIndex=0): We'll want to focus tab B (now in index 0)
// * B (tabIndex=1): We'll want to focus tab A (now in index 0)
// * C (tabIndex=2): We'll want to focus tab B (now in index 1)
// * D (tabIndex=3): We'll want to focus tab C (now in index 2)
const auto newSelectedIndex = std::clamp<int32_t>(tabIndex - 1, 0, _tabs.Size());
// _UpdatedSelectedTab will do the work of setting up the new tab as
// the focused one, and unfocusing all the others.
auto newSelectedTab{ _tabs.GetAt(newSelectedIndex) };
_UpdatedSelectedTab(newSelectedTab);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Also, we need to _manually_ set the SelectedItem of the tabView
// here. If we don't, then the TabView will technically not have a
// selected item at all, which can make things like ClosePane not
// work correctly.
_tabView.SelectedItem(newSelectedTab.TabViewItem());
}
}
// GH#5559 - If we were in the middle of a drag/drop, end it by clearing
// out our state.
if (_rearranging)
{
_rearranging = false;
_rearrangeFrom = std::nullopt;
_rearrangeTo = std::nullopt;
}
}
// Method Description:
// - Sets focus to the tab to the right or left the currently selected tab.
void TerminalPage::_SelectNextTab(const bool bMoveRight, const Windows::Foundation::IReference<Microsoft::Terminal::Settings::Model::TabSwitcherMode>& customTabSwitcherMode)
{
const auto index{ _GetFocusedTabIndex().value_or(0) };
const auto tabSwitchMode = customTabSwitcherMode ? customTabSwitcherMode.Value() : _settings.GlobalSettings().TabSwitcherMode();
if (tabSwitchMode == TabSwitcherMode::Disabled)
{
uint32_t tabCount = _tabs.Size();
// Wraparound math. By adding tabCount and then calculating
// modulo tabCount, we clamp the values to the range [0,
// tabCount) while still supporting moving leftward from 0 to
// tabCount - 1.
const auto newTabIndex = ((tabCount + index + (bMoveRight ? 1 : -1)) % tabCount);
_SelectTab(newTabIndex);
}
else
{
CommandPalette().SetTabs(_tabs, _mruTabs);
// Otherwise, set up the tab switcher in the selected mode, with
// the given ordering, and make it visible.
CommandPalette().EnableTabSwitcherMode(index, tabSwitchMode);
CommandPalette().Visibility(Visibility::Visible);
CommandPalette().SelectNextItem(bMoveRight);
}
}
// Method Description:
// - Sets focus to the desired tab. Returns false if the provided tabIndex
// is greater than the number of tabs we have.
// - During startup, we'll immediately set the selected tab as focused.
// - After startup, we'll dispatch an async method to set the the selected
// item of the TabView, which will then also trigger a
// TabView::SelectionChanged, handled in
// TerminalPage::_OnTabSelectionChanged
// Return Value:
// true iff we were able to select that tab index, false otherwise
bool TerminalPage::_SelectTab(uint32_t tabIndex)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
// GH#9369 - if the argument is out of range, then clamp to the number
// of available tabs. Previously, we'd just silently do nothing if the
// value was greater than the number of tabs.
tabIndex = std::clamp(tabIndex, 0u, _tabs.Size() - 1);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
auto tab{ _tabs.GetAt(tabIndex) };
// GH#11107 - Always just set the item directly first so that if
// tab movement is done as part of multiple actions following calls
// to _GetFocusedTab will return the correct tab.
_tabView.SelectedItem(tab.TabViewItem());
if (_startupState == StartupState::InStartup)
{
_UpdatedSelectedTab(tab);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
else
{
_SetFocusedTab(tab);
}
return true;
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
// Method Description:
// - This method is called once a tab was selected in tab switcher
// We'll use this event to select the relevant tab
// Arguments:
// - tab - tab to select
// Return Value:
// - <none>
void TerminalPage::_OnSwitchToTabRequested(const IInspectable& /*sender*/, const winrt::TerminalApp::TabBase& tab)
{
uint32_t index{};
if (_tabs.IndexOf(tab, index))
{
_SelectTab(index);
}
}
// Method Description:
// - Returns the index in our list of tabs of the currently focused tab. If
// no tab is currently selected, returns nullopt.
// Return Value:
// - the index of the currently focused tab if there is one, else nullopt
std::optional<uint32_t> TerminalPage::_GetFocusedTabIndex() const noexcept
{
// GH#1117: This is a workaround because _tabView.SelectedIndex()
// sometimes return incorrect result after removing some tabs
uint32_t focusedIndex;
if (_tabView.TabItems().IndexOf(_tabView.SelectedItem(), focusedIndex))
{
return focusedIndex;
}
return std::nullopt;
}
// Method Description:
// - returns the currently focused tab. This might return null,
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// so make sure to check the result!
winrt::TerminalApp::TabBase TerminalPage::_GetFocusedTab() const noexcept
{
if (auto index{ _GetFocusedTabIndex() })
{
return _tabs.GetAt(*index);
}
return nullptr;
}
// Method Description:
// - returns a com_ptr to the currently focused tab implementation. This might return null,
// so make sure to check the result!
winrt::com_ptr<TerminalTab> TerminalPage::_GetFocusedTabImpl() const noexcept
{
if (auto tab{ _GetFocusedTab() })
{
return _GetTerminalTabImpl(tab);
}
return nullptr;
}
// Method Description:
// - returns a tab corresponding to a view item. This might return null,
// so make sure to check the result!
winrt::TerminalApp::TabBase TerminalPage::_GetTabByTabViewItem(const Microsoft::UI::Xaml::Controls::TabViewItem& tabViewItem) const noexcept
{
uint32_t tabIndexFromControl{};
if (_tabView.TabItems().IndexOf(tabViewItem, tabIndexFromControl))
{
// If IndexOf returns true, we've actually got an index
return _tabs.GetAt(tabIndexFromControl);
}
return nullptr;
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Method Description:
// - An async method for changing the focused tab on the UI thread. This
// method will _only_ set the selected item of the TabView, which will
// then also trigger a TabView::SelectionChanged event, which we'll handle
// in TerminalPage::_OnTabSelectionChanged, where we'll mark the new tab
// as focused.
// Arguments:
// - tab: tab to focus.
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Return Value:
// - <none>
winrt::fire_and_forget TerminalPage::_SetFocusedTab(const winrt::TerminalApp::TabBase tab)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
// GH#1117: This is a workaround because _tabView.SelectedIndex(tabIndex)
// sometimes set focus to an incorrect tab after removing some tabs
auto weakThis{ get_weak() };
co_await winrt::resume_foreground(_tabView.Dispatcher());
if (auto page{ weakThis.get() })
{
// Make sure the tab was not removed
uint32_t tabIndex{};
if (_tabs.IndexOf(tab, tabIndex))
{
_tabView.SelectedItem(tab.TabViewItem());
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
// Method Description:
// - Close the currently focused pane. If the pane is the last pane in the
// tab, the tab will also be closed. This will happen when we handle the
// tab's Closed event.
winrt::fire_and_forget TerminalPage::_CloseFocusedPane()
{
if (const auto terminalTab{ _GetFocusedTabImpl() })
{
_UnZoomIfNeeded();
if (const auto pane{ terminalTab->GetActivePane() })
{
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
if (pane->ContainsReadOnly())
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
ContentDialogResult warningResult = co_await _ShowCloseReadOnlyDialog();
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
// If the user didn't explicitly click on close tab - leave
if (warningResult != ContentDialogResult::Primary)
{
co_return;
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
// Clean read-only mode to prevent additional prompt if closing the pane triggers closing of a hosting tab
pane->WalkTree([](auto p) {
if (const auto control{ p->GetTerminalControl() })
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
if (control.ReadOnly())
{
control.ToggleReadOnly();
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
return false;
});
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 21:16:05 +02:00
pane->Close();
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
else if (auto index{ _GetFocusedTabIndex() })
{
const auto tab{ _tabs.GetAt(*index) };
if (tab.try_as<TerminalApp::SettingsTab>())
{
_HandleCloseTabRequested(tab);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
}
// Method Description:
// - Close the tab at the given index.
void TerminalPage::_CloseTabAtIndex(uint32_t index)
{
if (index >= _tabs.Size())
{
return;
}
if (auto tab{ _tabs.GetAt(index) })
{
_HandleCloseTabRequested(tab);
}
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Method Description:
// - Closes provided tabs one by one
// Arguments:
// - tabs - tabs to remove
winrt::fire_and_forget TerminalPage::_RemoveTabs(const std::vector<winrt::TerminalApp::TabBase> tabs)
{
for (auto& tab : tabs)
{
co_await _HandleCloseTabRequested(tab);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
// Method Description:
// - Responds to changes in the TabView's item list by changing the
// tabview's visibility.
// - This method is also invoked when tabs are dragged / dropped as part of
// tab reordering and this method hands that case as well in concert with
// TabDragStarting and TabDragCompleted handlers that are set up in
// TerminalPage::Create()
// Arguments:
// - sender: the control that originated this event
// - eventArgs: the event's constituent arguments
void TerminalPage::_OnTabItemsChanged(const IInspectable& /*sender*/, const Windows::Foundation::Collections::IVectorChangedEventArgs& eventArgs)
{
if (_rearranging)
{
if (eventArgs.CollectionChange() == Windows::Foundation::Collections::CollectionChange::ItemRemoved)
{
_rearrangeFrom = eventArgs.Index();
}
if (eventArgs.CollectionChange() == Windows::Foundation::Collections::CollectionChange::ItemInserted)
{
_rearrangeTo = eventArgs.Index();
}
}
CommandPalette().Visibility(Visibility::Collapsed);
_UpdateTabView();
}
// Method Description:
// - Additional responses to clicking on a TabView's item. Currently, just remove tab with middle click
// Arguments:
// - sender: the control that originated this event (TabViewItem)
// - eventArgs: the event's constituent arguments
void TerminalPage::_OnTabClick(const IInspectable& sender, const Windows::UI::Xaml::Input::PointerRoutedEventArgs& eventArgs)
{
if (eventArgs.GetCurrentPoint(*this).Properties().IsMiddleButtonPressed())
{
const auto tabViewItem = sender.try_as<MUX::Controls::TabViewItem>();
if (auto tab{ _GetTabByTabViewItem(tabViewItem) })
{
_HandleCloseTabRequested(tab);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
eventArgs.Handled(true);
}
else if (eventArgs.GetCurrentPoint(*this).Properties().IsRightButtonPressed())
{
eventArgs.Handled(true);
}
}
void TerminalPage::_UpdatedSelectedTab(const winrt::TerminalApp::TabBase& tab)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
// Unfocus all the tabs.
for (auto tab : _tabs)
{
tab.Focus(FocusState::Unfocused);
}
try
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
_tabContent.Children().Clear();
_tabContent.Children().Append(tab.Content());
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// GH#7409: If the tab switcher is open, then we _don't_ want to
// automatically focus the new tab here. The tab switcher wants
// to be able to "preview" the selected tab as the user tabs
// through the menu, but if we toss the focus to the control
// here, then the user won't be able to navigate the ATS any
// longer.
//
// When the tab switcher is eventually dismissed, the focus will
// get tossed back to the focused terminal control, so we don't
// need to worry about focus getting lost.
if (CommandPalette().Visibility() != Visibility::Visible)
{
tab.Focus(FocusState::Programmatic);
_UpdateMRUTab(tab);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
tab.TabViewItem().StartBringIntoView();
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Raise an event that our title changed
if (_settings.GlobalSettings().ShowTitleInTitlebar())
{
_TitleChangedHandlers(*this, tab.Title());
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
CATCH_LOG();
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
// Method Description:
// - Responds to the TabView control's Selection Changed event (to move a
// new terminal control into focus) when not in in the middle of a tab rearrangement.
// Arguments:
// - sender: the control that originated this event
// - eventArgs: the event's constituent arguments
void TerminalPage::_OnTabSelectionChanged(const IInspectable& sender, const WUX::Controls::SelectionChangedEventArgs& /*eventArgs*/)
{
if (!_rearranging && !_removing)
{
auto tabView = sender.as<MUX::Controls::TabView>();
auto selectedIndex = tabView.SelectedIndex();
if (selectedIndex >= 0 && selectedIndex < gsl::narrow_cast<int32_t>(_tabs.Size()))
{
const auto tab{ _tabs.GetAt(selectedIndex) };
_UpdatedSelectedTab(tab);
}
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
// Method Description:
// - Updates all tabs with their current index in _tabs.
// Arguments:
// - <none>
// Return Value:
// - <none>
void TerminalPage::_UpdateTabIndices()
{
const uint32_t size = _tabs.Size();
for (uint32_t i = 0; i < size; ++i)
{
auto tab{ _tabs.GetAt(i) };
auto tabImpl{ winrt::get_self<TabBase>(tab) };
tabImpl->UpdateTabViewIndex(i, size);
}
}
// Method Description:
// - Bumps the tab in its in-order index up to the top of the mru list.
// Arguments:
// - tab: tab to bump.
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
// Return Value:
// - <none>
void TerminalPage::_UpdateMRUTab(const winrt::TerminalApp::TabBase& tab)
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
uint32_t mruIndex;
if (_mruTabs.IndexOf(tab, mruIndex))
{
if (mruIndex > 0)
{
_mruTabs.RemoveAt(mruIndex);
_mruTabs.InsertAt(0, tab);
}
}
}
// Method Description:
// - Moves the tab to another index in the tabs row (if required).
// Arguments:
// - currentTabIndex: the current index of the tab to move
// - suggestedNewTabIndex: the new index of the tab, might get clamped to fit int the tabs row boundaries
// Return Value:
// - <none>
void TerminalPage::_TryMoveTab(const uint32_t currentTabIndex, const int32_t suggestedNewTabIndex)
{
auto newTabIndex = gsl::narrow_cast<uint32_t>(std::clamp<int32_t>(suggestedNewTabIndex, 0, _tabs.Size() - 1));
if (currentTabIndex != newTabIndex)
{
auto tab = _tabs.GetAt(currentTabIndex);
auto tabViewItem = tab.TabViewItem();
_tabs.RemoveAt(currentTabIndex);
_tabs.InsertAt(newTabIndex, tab);
_UpdateTabIndices();
_tabView.TabItems().RemoveAt(currentTabIndex);
_tabView.TabItems().InsertAt(newTabIndex, tabViewItem);
_tabView.SelectedItem(tabViewItem);
}
}
void TerminalPage::_TabDragStarted(const IInspectable& /*sender*/,
const IInspectable& /*eventArgs*/)
{
_rearranging = true;
_rearrangeFrom = std::nullopt;
_rearrangeTo = std::nullopt;
}
void TerminalPage::_TabDragCompleted(const IInspectable& /*sender*/,
const IInspectable& /*eventArgs*/)
{
auto& from{ _rearrangeFrom };
auto& to{ _rearrangeTo };
if (from.has_value() && to.has_value() && to != from)
{
auto& tabs{ _tabs };
auto tab = tabs.GetAt(from.value());
tabs.RemoveAt(from.value());
tabs.InsertAt(to.value(), tab);
_UpdateTabIndices();
}
_rearranging = false;
from = std::nullopt;
to = std::nullopt;
}
void TerminalPage::_DismissTabContextMenus()
{
for (const auto& tab : _tabs)
{
if (tab.TabViewItem().ContextFlyout())
{
tab.TabViewItem().ContextFlyout().Hide();
}
}
}
void TerminalPage::_FocusCurrentTab(const bool focusAlways)
{
// We don't want to set focus on the tab if fly-out is open as it will
// be closed TODO GH#5400: consider checking we are not in the opening
// state, by hooking both Opening and Open events
if (focusAlways || !_newTabButton.Flyout().IsOpen())
{
// Return focus to the active control
if (auto tab{ _GetFocusedTab() })
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
{
tab.Focus(FocusState::Programmatic);
_UpdateMRUTab(tab);
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
}
}
}
bool TerminalPage::_HasMultipleTabs() const
{
return _tabs.Size() > 1;
}
void TerminalPage::_RemoveAllTabs()
{
// Since _RemoveTabs is asynchronous, create a snapshot of the tabs we want to remove
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
std::vector<winrt::TerminalApp::TabBase> tabsToRemove;
std::copy(begin(_tabs), end(_tabs), std::back_inserter(tabsToRemove));
_RemoveTabs(tabsToRemove);
}
void TerminalPage::_ResizeTabContent(const winrt::Windows::Foundation::Size& newSize)
{
for (auto tab : _tabs)
{
if (auto terminalTab = _GetTerminalTabImpl(tab))
{
terminalTab->ResizeContent(newSize);
}
}
}
}