@bpasero anything else you need on my end? I know there's a lot of PRs to get through, just wanted to make sure I'm not missing any requirements.

Hey @bpasero, any word?

Maybe I am missing some context but the related issue did not get a lot of upvotes, so we have to assume that the drop target is just fine for most people and now we are changing it based on what assumption?

Maybe I am missing some context but the related issue did not get a lot of upvotes,

I suspect the related issue doesn't have many upvotes because it's so hard to find any given issue in the sea of them. And there's no standard way (that I'm aware of) to ask for upvotes. (e.g. there's no official slack or discord or other place to talk about VS Code the way there was for atom)

so we have to assume that the drop target is just fine for most people and now we are changing it based on what assumption?

I wouldn't call Fitts' Law (the ease of hitting a mouse target is a function of the size of the target and the distance to it) an assumption. Anecdotally, I have talked to coworkers across several companies who think the target is too small, and I know I've frequently missed it myself. It's also a bigger issue for those on laptops than desktops. Dragging with a touchpad (especially a long distance) is rough.

The ideal of course would be to have this configurable, but I don't have enough experience in VS Code's internals to make that change myself. I chose 25% because it's a small change and leaves the default drop target (inside the pane) still the largest area.

woah woah. that issue has been "marked as locked" so that others can't upvote it now either 👏
that's why i advocate for "not planned" issues to be left unlocked normally - to be locked only with human intervention when there are waged keyboard-wars or way too many spam "+1" or "me too" comments

anyhow, i went there to reply to this:

if you have any examples of other issues asking for this, I can add them to my PR for it. 🤞 we can get this merged, it's one of the few remaining annoyances for me switching from atom.

yes, found one more: #198603 @jacekkopecky you can interact, discuss and contribute here 😃

@goyalyashpal @calebmeyer sorry I missed the previous issue and this PR in my search, and it baffles me that #184580 was treated as a feature request.

This PR only deals with dragging a single editor, and leaves the group-dragging case alone, I'd say the behaviours should be consistent, and the code could be simplified nicely.

I'm hoping that the maintainer chime in with what changes would be acceptable. The problems I listed in my issue lead to three things that can be done:

1. increasing the threshold (e.g. to 25% like in this PR), or making it configurable,
2. making dragging a single editor and dragging a group use the same drag target areas,
3. removing the confusing horseshoe shapes.

Number 1 above is common with this PR and with #184580. What do you think about the other points?

3. removing the confusing horseshoe shapes.

i don't think that a better solution exists - as dropping in center to change editor group can also be a common a requirement
besides, increasing the drop target area would reduce the horshoe shape quite a lot.

2. making dragging a single editor and dragging a group use the same drag target areas,

i have never seen or even thought that a group can be dragged. can you share a screenrecording? (use sharex if you don't have any screen recording software)

thanks :)

I'd very much like the target size to be configurable, or just larger. The current implementation is optimal on a single monitor, especially a small one like a laptop, where you can just throw the tab against the edge of the screen and let go.

I use VScode on the left of two large monitors side by side. I can't throw tabs to the left, as then they land in the sidebar. I can't throw them to the right, as then I overshoot and I end up dropping them on the other monitor.

Instead I have to manually aim at the drop zone within the vscode editor panes, and it's simply too small to do this conveniently. I have to drag the tabs way past the point where the intended action is clear.

@goyalyashpal Hi, I'm not advocating that we remove dropping in the center - that is definitely something we need to be able to do. :)

In #198603 I have an image of the horseshoe shape - with the setting openSideBySideDirection being right, the left and right drop areas are themselves horseshoe-shaped. This doesn't make sense to me - you can go from being in the right area (at the top), move your cursor down and right, and suddenly the drop area changes to the center.

I would like the drop areas to be convex, e.g. like this:

As for dragging groups, you can grab an editor group by the empty space after tabs (if you have fewer tabs open than space available).

I see you down-voted that issue, why?

@JonnieCache you're absolutely right. I don't run my VSCode full-screen much so I never even realized that the drag areas reach the sides of the monitor. And even in full screen, various panels would tend to be on the sides of my editor.

@goyalyashpal thanks, now I understand. Would you and @JonnieCache like to upvote #198603 then? :)

I stand by what I said before: changing this will potentially make it worse for all people that are happy with the current state of things. If at all we want to allow a change here, it would have to be gated behind a setting imho, that leaves it as it is today by default.

Does that make sense?