Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for moving panes and tabs between windows #14866

Merged
merged 228 commits into from
Mar 30, 2023

Conversation

zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Feb 17, 2023

Lo! Harken to me, for I shall divulge the heart of the tab tear-out saga. Verily, this PR shall bestow upon thee the power to move tabs and panes between windows by means of pre-defined actions. Though be warned, it does not yet grant thee the power to drag and drop them as thou mayest desire. Yet, the same plumbing that underpins this work shall remain steadfast. Behold, the majority of this undertaking concerns the elevation of the RequestMoveContent event from the TerminalPage to the very summit of the Monarch. From thence, a great AttachContent method shall descend back to the lowest depths. Furthermore, there are minor revisions to TermControl that shall enable thee to better detach the content and attach it to a new one.

This is the most important part of the tab tear-out saga. This PR enables the user to move tabs and panes between windows using pre-defined actions. It does not enable the user to drag/drop them yet, but the same fundamental plumbing will still apply. Most of the PR is plumbing the RequestMoveContent event up from the TerminalPage up to the Monarch, and then plumbing an AttachContent method back down. There are also small changes to TermControl to better support detaching the content and attaching to a new one.

For testing, I recommend:

        { "keys": "f1", "command": { "action": "moveTab", "window": "1" } },
        { "keys": "f2", "command": { "action": "moveTab", "window": "2" } },

        { "keys": "f3", "command": { "action": "movePane", "window": "1" } },
        { "keys": "f4", "command": { "action": "movePane", "window": "2" } },

        { "keys": "shift+f3", "command": { "action": "movePane", "window": "1", "index": 3 } },
        { "keys": "shift+f4", "command": { "action": "movePane", "window": "2", "index": 3 } },

…ing AppLogic that I hate so I'm gonna start over
  We'll need this for #5000, for ainulindale. This refactoring will be annoying
  enough as it is so we may as well do it as a first, separate PR.
…ndale

# Conflicts:
#	src/cascadia/WindowsTerminal/AppHost.h
…XAML island is started.

  I think this can work in the parent at least
…It launches and crashes immediately. We'll keep shuffling code.
  At this point, I determined that I would need to make some big changes to
  AppHost and decided that it was time to commit before moving on.
…pressive

  It exits itself after 30s, but hey it worked
There's a lot of renaming, signature changes here. But StartupActions is a good mechanism for passing panes around, more or less.

cherry-picked from cfe879d
  but it doesn't render, and the old pane keeps on choochin.

  And it only works with a window name, not and ID

  And the `Dispatcher` definitely needs to get re-wired for the new thread, cause dragging it across a DPI boundary (aka, resize) crashes the window
  This is basically the comment from aaefdf4. The other comment wasn't relevant anymore
@zadjii-msft zadjii-msft assigned zadjii-msft and unassigned DHowett Mar 28, 2023
@zadjii-msft zadjii-msft added the Product-Terminal The new Windows Terminal. label Mar 28, 2023
@DHowett
Copy link
Member

DHowett commented Mar 29, 2023

Pass audit too!

@DHowett
Copy link
Member

DHowett commented Mar 29, 2023

And fix pre-existing, spellbot hates it

@zadjii-msft zadjii-msft enabled auto-merge (squash) March 30, 2023 13:56
@zadjii-msft zadjii-msft merged commit 17a5b77 into main Mar 30, 2023
@zadjii-msft zadjii-msft deleted the dev/migrie/oop/3/quenta-silmarillion branch March 30, 2023 14:37
@@ -39,8 +39,17 @@ namespace winrt::TerminalApp::implementation
return it != _content.end() ? it->second : ControlInteractivity{ nullptr };
}

void ContentManager::_closedHandler(winrt::Windows::Foundation::IInspectable sender,
winrt::Windows::Foundation::IInspectable e)
void ContentManager::Detach(const Microsoft::Terminal::Control::TermControl& control)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Part of me feels like we should only use ContentIds here in ContentManager. There's a crossing of concerns, giving ContentManager access (in any form!) to non-free-threaded UI objects!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But... what does this function do? It looks like it doesn't need to be inside the content manager at all, since it mostly operates on control and never returns the detached content or even confirms whether it did detach anything..!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants