Repository: PowerToys
Issue: Windows snap override behavior issues and possible solution.
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

![image](https://user-images.githubusercontent.com/6697473/153828053-284a843e-9208-40ea-b41b-66621ec027b5.png)

State diagram of desired behavior with Windows Snap override. Criticism of current behavior in supporting information.

A potential algorithm might be the following. The currently selected window can be anywhere on the screen when this runs and it should have good results. This could even take other screens into account. This is essentially better relative mode.
> **zones** = list of zones, with midpoint information
> **if** windows_key **is** pressed **and** arrow_key_up/down/left/right **is** pressed:
>&nbsp;&nbsp;&nbsp;&nbsp;**direction** = whichever arrow key was pressed
>&nbsp;&nbsp;&nbsp;&nbsp;**selected_midpoint** = currently selected window's midpoint
>&nbsp;&nbsp;&nbsp;&nbsp;**using_x_coordinate** = if arrow_direction is left or right
>&nbsp;&nbsp;&nbsp;&nbsp;**using_less_than**= if arrow_direction is left or down
>&nbsp;&nbsp;&nbsp;&nbsp;**if** using_x_coordinate:
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**possible_zones** = zones **filtered by** x being **(using_less_than ? <= : >= )** selected_midpoint's x
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**possible_zones** = **possible_zones** - current zone
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**target_zone** = **first element of** the list of possible_zones
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**sorted by** Euclidean distances to selected_midpoint
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**then** y coordinate **lowest to highest**
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**then** zone size **biggest to smallest**
>&nbsp;&nbsp;&nbsp;&nbsp;*# add else and use y for x and x for y instead, omitted for brevity*
>&nbsp;&nbsp;&nbsp;&nbsp;**move** selected window to target_zone

### Scenario when this would be used?

- Up, up is much easier to hit to go to fullscreen than up, right or up, left depending on where the window even ends up.
- The proposed window layout is just a union of the three simplest window positions. I'm advising the most natural way to move between them.

### Supporting information

No combination of settings for "Move window based on" gives this behavior. The way this actually works is a mess. Particularly when combining FancyZone land with Windows Snap land by letting it handle up and down. However, with relative position mode, up will never go from left to full. It would be useful to think about the full + half + quarters case as well, as that also cycles between stuff on the left side of the screen and never goes full.

Additionally, the way this feature works when snapping by dragging to the edge is unpredictable as well, as this brings you into Windows Snap land.