-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MEGATHREAD] Tab drag/drop/tear-out gaps #14900
Labels
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
External-Blocked-WinUI3
We can't progress until WinUI3 exists.
Issue-Scenario
Product-Terminal
The new Windows Terminal.
Milestone
Comments
microsoft-github-policy-service
bot
added
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
Needs-Tag-Fix
Doesn't match tag requirements
labels
Feb 23, 2023
zadjii-msft
added
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
Product-Terminal
The new Windows Terminal.
Issue-Scenario
labels
Feb 23, 2023
zadjii-msft
removed
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
Needs-Tag-Fix
Doesn't match tag requirements
labels
Feb 23, 2023
This comment was marked as off-topic.
This comment was marked as off-topic.
6 tasks
This comment was marked as off-topic.
This comment was marked as off-topic.
zadjii-msft
added a commit
that referenced
this issue
Mar 30, 2023
_Behold, the penultimate chapter in the saga of tear-out! This significant update bestows upon the user the power to transport tabs betwixt Terminal windows. Alas, the drag and drop capabilities of TabView are not yet refined, so this PR primarily concerns itself with the intricacies of plumbing. When a tab is extracted and deposited elsewhere, it is necessary to have the recipient make an inquiry to the Monarch, who in turn will beseech the sender to transmit the tab content, akin to the act of moving a tab. Curious it may seem, but the method has proven effective._ The penultimate tear-out PR. This PR enables the user to move tabs from one Terminal window to another. The TabView drag/drop APIs have some rough edges, so this PR is mostly plumbing. When a tab is drag/dropped, we need to get the recipient to ask the Monarch to ask the sender to send the tab content, like a MoveTab action. Wacky, but it works. There's a LONG tail of UX gaps. Those I'm going to track in #14900. It is more valuable for us to merge this now than to figure out workarounds immediately. The next PR will be the last main PR in this saga - in which we enable dragging a tab out of the window and dropping to create a new window. * Closes #1256 * Related to #5000 * Follow-ups get to go in #14900 ## Detailed description As I mentioned, it's mostly plumbing. The order that we get tab drag events is... unfortunate... for our use case. So we do a lot of sending `RequestReceiveContentArgs` up and down between windows, just to communicate who the tab was dropped on to whomever the tab was dragged from. There's a diagram for this that I originally put in #5000 (comment): ```mermaid sequenceDiagram participant Source participant Target participant Monarch Note Left of Source: _onTabDragStarting Source --> Source: stash dragged content Source --> Source: pack window ID into DataPackage Source ->> Target: Drag tab Note right of Target: _onTabStripDragOver Target ->> Target: AcceptedOperation(DataPackageOperation::Move) Source --> Target: Release mouse (to drop) Note right of Target: _onTabStripDrop Target --> Target: get WindowID from DataPackage Target -) Monarch: Request that WindowID sends content to us<br>RequestRecieveContent Monarch -) Source: Tell to send content to Target.Id<br>RequestSendContent, SendContent Source --> Source: detach our content Source -) Monarch: RequestMoveContent(stashed, target.id) Monarch -) Target: AttachContent(stashed) # Target -->> Source: # Note Left of Source: TabViewTabDragStartingEventArgs<br>.OperationCompleted # Note Left of Source: _onTabDroppedCompleted ``` Really really though, let's try to avoid nits about the UX at this time. This PR works with what we've got. Mail threads are percolating. I've got 19 chapters worth of Hobbit branch names to use for those follow ups.
zadjii-msft
added
the
External-Blocked-WinUI3
We can't progress until WinUI3 exists.
label
May 8, 2024
Pretty sure just about everything in this thread would get solved by the WinUI 3 tab tear-out implementation if we could move to it |
There's not a "merge all windows/tabs into single window" option yet, right? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
External-Blocked-WinUI3
We can't progress until WinUI3 exists.
Issue-Scenario
Product-Terminal
The new Windows Terminal.
A follow-up to #1256 and #5000. Now that those are in the final stages, it has become more obvious where the papercuts lie.
We CANNOT fix it
"Tear out v1" gaps
Things that are obvious gaps in the initial version of drag/drop. Firefox-like (hopefully).
Move ↗
for successful ones, either. So that's ridiculous.AllowDependentAnimations(false)
then re-enable. Presumably they're independent animationsGetWindowPlacement
The fullness of time gaps
Given infinite engineering resources, what would we like the experience to be? Basically, Chromium-like or better.
Note that this experience is currently blocked entirely for Terminal. We'll need to be able to switch to WinUI 3 (WASDK 1.6) before we can use the new tab APIs they provided
Resources
Notes to myself on internal threads to investigate
The text was updated successfully, but these errors were encountered: