microsoft
FancyZones: Drag to snap a window to multiple zones should use window position instead of mouse cursor
Currently FancyZones uses the mouse cursor position to determine whether a window should be snapped to multiple zones. I suggest the center of the window be used instead.
When dragging a window to snap, it should snap to multiple zones if the window center is near an edge between zones. Currently it depends on the mouse cursor position, which can be a little confusing. It would also be more intuitive in scenarios where a window is dragged to clearly lie within one zone but the mouse cursor happens to lie near an edge.
If you'd like to see this feature implemented, add a 👍 reaction to this post.
How would this work for monitor edges? Example, if i'm dragging a large window to the right most zone and my zone is tiny and my cursor grab on the title bar.
The right mouse grab + right zone makes it impossible to have certain size windows. If it is based on the mouse location, you will never get into a scenario like this
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days. It will be closed if no further activity occurs within 5 days of this comment.
Yeah, some thought would have to be put into these "edge cases" 😉 A simple hack would be to just revert to current behaviour when touching a monitor edge.
Alternatively, a better user experience might be to have the window step through relevant zones when the user drags and holds the window to an edge. But that would be more complex to program.
That's just a couple ideas... there are likely better ones.
How would this work for monitor edges? Example, if i'm dragging a large window to the right most zone and my zone is tiny and my cursor grab on the title bar.
The right mouse grab + right zone makes it impossible to have certain size windows. If it is based on the mouse location, you will never get into a scenario like this
There is no disambiguation method without a non-working edge case.
The mouse-center disambiguation method fails if you have two fancyzones with the same center, one tall, one wide. For example, in a 3 monitor setup where you have a zone per monitor, and then another overlap zone spanning all three monitors. because the union and center monitor will both have the same-ish center and thus too small a disambiguation target. Curiously all of these disambiguation methods fail in this case today.
The smallest/largest options fail if your overlapping smaller zones don't have a gap, which occurs in the above layout even if you only have two zones.
This does not make these disambiguation methods bad, it just means no method works for all setups. That is why we need multiple disambiguation methods for different ways people use fancyzones. I personally don't have any "tiny side zones" so the stated disambiguation issue is irrevant to me, which is why I'm happy for FanzyZones to have the "mouse center" option for those who prefer it, but I would prefer "window center"
implementation idea for window-center
I think it would be reasonable, when implementing window-center, to automatically switch to "mouse-center" when the mouse is in contact with a non-passable edge of a monitor (aka edge of usable desktop area). I think this combination of using window-center normally, and mouse-center when touching an impassable edge would provide a much more natural "feel" most of the time, rather than either window-center or mouse-location always.
However, this method would requre the small "side zone" to actually touch the screen edge. Otherwise your mouse won't be over any zone when you are touching the screen edge. Tradeoffs, tradeoffs.
idea for even more rich disambiguation
Another method to handle tricky disambiguation issues would be to add an option "non-primary mouse button cycles overlapping zones". so if you were holding a window with left-mouse, and you were getting the wrong overlap region, you could tap right-mouse to cycle to the next overlapping region. This still requires defining which zones qualify as "overlapping" (aka window-extent, window-center, or mouse-location).
This is conceptually similar to, but different from, the existing option "use non-primary mouse button to toggle zone activation" which probably needs a better description or tooltip because even trying it I have no idea what it does.
why I want window-center:
I've used FanzyZones for over 6 years, using the only existing option that works for my setup "Activate the zone whose center is closest to the cursor" and it's just never feels right. This is my 3-monitor setup:
The smallest/largest options are not usable, because the gap between the smaller zones is too small a disambiguation target to "find quickly" for the larger zone.
Using mouse-cursor has a weird feel because I can't just drop a window onto the zones by looking at the HUGE WINDOW i'm dragging, I have to focus on the tiny cursor. Today I often drag a window to where I want it to land, expecting the window center to control the landing spot, but because I grabbed the titlebar on the right side, it doesn't pick the right zone, so then I have to shift the window way off to the side to get the CURSOR where fancyzones needs it. I believe this whole thing would be much more natural for me using window-center for the disambiguation.
I admit this idea works for me because all my overlaps are 2-split, which provides 3 very obvious different center targets. Every disambiguation method we have fails for people with three-split overlaps. In a 3-split overlap, the center subregion and the union region both have a similar center, and larger and smaller will always pick one or the other, so they probably need some extra button disambiguation like I explained above.
Ironically, from my layout, you can see that what I'm doing is not far off from the windows built-in snapping... but I don't want windows to snap unless I'm holding shift, and there is no way to do this with the windows built in snapping.
