Dragging tabs between screens of different dpi glitches

[titoBouzout]

Description of the bug

Primary screen on the laptop: 2k 150% 2560x1440 Secondary vertical screen: 100% 1080x1920

Dragging the tab from the secondary screen to the primary screen glitches Dragging the tab from the primary screen to the secondary screen glitches

This makes it very difficult to drag a tab to an existing window.

Steps to reproduce

1. have two screens with different dpi
2. have two sublime text open on both screens
3. drag one tab to the other screen

Expected behavior

-

Actual behavior

-

Sublime Text build number

4172

Operating system & version

Windows 10

(Linux) Desktop environment and/or window manager

No response

Additional information

from 0:00 I'm trying to drag to my primary screen from 0:24 I'm trying to drag to my secondary screen https://github.com/sublimehq/sublime_text/assets/64156/de23a63f-b258-4198-8bb4-cb4a62c8df58

OpenGL context information

No response

[BenjaminSchaaf]

Fixed in build 4173.

[titoBouzout]

Thanks Benjamin, the tab follows the cursor and draws correctly, but the drop target is messed up.

Dragging Tab from "screen 2 - 100% 1080x1920" To "screen 1 - 2k 150% 2560x1440"

• The drop target horizontally works only 3/4 and the rest 1/4 it behaves as if there were no drop target
• The drop target vertically seems to be the menubar instead of the tab-bar (video follows)

Dragging Tab from "screen 1 - 2k 150% 2560x1440" high dpi To "screen 2 - 100% 1080x1920"

• There's no drop target (the tab-bar doesn't magnet the tab I am dragging, and I cant find a drop target at all)
• Releasing the tab creates a new window on screen 1 instead of 2

Dragging Tab to very same Screen the Tab is dragged from:

• works flawless and pixel perfect on both screens, between instances and different layouts.

https://github.com/sublimehq/sublime_text/assets/64156/01fdb20a-65da-4675-a5a0-bb444daa15fd

[titoBouzout]

@BenjaminSchaaf do you want me to enter this issue as a new one? I still consider it the same one, but I could enter a new one specific for "drop target"

[BenjaminSchaaf]

No need to open a new one.

[titoBouzout]

@BenjaminSchaaf maybe the buffer could be added as drop target? that would make it easier to move tabs between panes, and will probably make it work moving tabs between screens.

[BenjaminSchaaf]

Should be fixed in build 4174.

[titoBouzout]

Thanks! Did some quick tests and everything works great between editors. There's 1 remaining issue, and two other comments that I am not sure about it.

Issue:

• dragging and dropping a tab to a screen that doesn't have an instance of ST running, creates a window on the screen that the tab is being dragged from, instead of creating the window on the screen the tab has been dropped into. This is reproducible most of the time, like 90%, but sometimes it does the right thing, I couldn't figure out a pattern to make it reproducible 100% of the time.

Feature:

• allow the tab to be dropped on the editor buffer. I am not sure if this is a good idea, maybe if the drop target height could be extended to also include the editor buffer?

Fancy Zones:

• the tab being dragged is not recognized by Fancy Zones as a window/popup. Fancy Zones is the window tilling manager of power toys. Its a great tool because creates drop targets that will position and re/size the dropped window into it, making it very easy to manage windows between screens. ST windows works with fancy zones, dragging Chrome tabs too. I am not sure if you can make it work with the tabs being dragged that would be great. I don't use Windows 11 but they seem to have a similar feature possible working with similar internals Snap Windows / Windows Snapping.

The first issue is related to the recent improvements to tab drag and dropping. The other two idk, I can add them as separated issues. Let me know, thanks!

[titoBouzout]

@BenjaminSchaaf just ccing you in case it has been missed

[BenjaminSchaaf]

Reopening for that issue. The rest I'd ask you to report separately, though extending the drop target to the whole buffer is unlikely to ever happen for various reasons.

[titoBouzout]

ok, thanks, reopening for :

• dragging and dropping a tab to a screen that doesn't have an instance of ST running, creates a window on the screen that the tab is being dragged from, instead of creating the window on the screen the tab has been dropped into. This is reproducible most of the time, like 90%, but sometimes it does the right thing, I couldn't figure out a pattern to make it reproducible 100% of the time.

[titoBouzout]

@BenjaminSchaaf entered https://github.com/sublimehq/sublime_text/issues/6387 for fancy zones, and reopened this one for the tab dragging to a screen that doesn't have a Sublime Text instance running.