terminal
terminal copied to clipboard
[MEGATHREAD] Tab drag/drop/tear-out gaps
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
- [ ] You cannot drag / drop tabs as admin.
- See #6661
- [ ] When tearing-out with touch, the tab will appear where the pointer is. NOT where the touch is.
- I'm told there's no way to get the touch position at the end of the drag.
"Tear out v1" gaps
Things that are obvious gaps in the initial version of drag/drop. Firefox-like (hopefully).
- [ ] Tabs have no preview of what's being dragged
- [ ] Tabs can only be dropped on the TabView, but not the whole titlebar
- [ ] The tab item corners are rounded on top, and flat on the bottom
- [ ] #15438
- The tab view item shows a 🚫 when dragging over not the Terminal, even though you totally can just drop there to make a new window
- There is a way in the Sept'23 OS release to suppress the drag icon, however, this ENTIRELY suppresses the drag icon. That means there's no
Move ↗for successful ones, either. So that's ridiculous.
- [ ] VsCode shows that it can accept a "Move" of a Terminal tab, even though that's obviously insane
- [ ] The tab view of the target doesn't expand to make room for the new tab. It makes a gap, but it doesn't increase its width, so the existing tabs are clipped on the right
- [ ] The target doesn't show a preview of the dragged tab's content "in place" when hovering over the tab view
- [ ] We shouldn't "animate in" tab items when dropping. They should just appear
- It wasn't trivial to just
AllowDependentAnimations(false)then re-enable. Presumably they're independent animations
- It wasn't trivial to just
- [ ] pressing escape should stop the drag and put the window back where it started
- [ ] while tab dragging, if you drag over another window (and switch to 'move' in the image being dragged), the window you've dragged over should be raised in zorder. this could expose places to drop the tab.
- [ ] if window is snapped and you drag a tab out, you're using the snap rect (so, left snap and drag out would be as tall as the monitor). You should use the normal position,
GetWindowPlacement - [ ] https://github.com/microsoft/microsoft-ui-xaml/issues/8442
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
- [ ] #16129
- Including, but not limited to:
- [ ] Tabs should make a new window as soon as their torn out
- [ ] Torn-out tabs need to be able to snap to snap positions (maximized, snap layouts) without dropping first
- [ ] Multiple tabs can't be dragged/dropped all at once
- [ ] Dragging a tab in a window with a single tab should just drag the window
Resources
Notes to myself on internal threads to investigate
- MSFT:42334223: TabView Crash when moving tab in dozens of tabs
- os.2020!8180615: Suppressing drag feedback icon while dragging a tab
Notes from use:
- Opening settings in two windows at the same time causes a crash.
- I went into settings to turn on the tray icon, and it crashed when I hit Save.
- I launched an elevated profile, then closed it, and admin terminal stuck around in the tray
@DHowett I'm gonna move those notes to #14957 (yikes what a gross number). I wanna focus this thread on specifically the tab drag/drop UX, while those are more process model v3-specific. That cool?
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?