[Bug] FancyZones: settings does exact opposite of what it states

[DavidGretzschel]

Version: 10.0.18362 Build 18362
0.13
"Keep windows in their zones when the active FancyZones layout changes"
It's a flawed feature anyway, since there's no clear relationship between old zone and new zone, if the next layout does not have the same number of zones. In spite of that, it just reassigns wildly.
Don't see how that's useful. Perhaps if the editor would visibly number the zones, but it doesn't do that.
video:
https://www.loom.com/share/102cde12e5cf47a6999115e3ab6b791d

[enricogior]

It turned out the code does what is suppose to do, it's the setting description that is kind of confusing (I got confused as well!).

[enricogior]

@crutkas
can you please review this FZ setting description that is quite confusing compared to what is supposed to do.
The setting is:

Keep windows in their zones when the active FancyZones layout changes

but as correctly explained in the FZ readme:

When this option is on, Fancy Zones will resize and position windows into the new zone layout by maintaining the previous zone number location of each window

In one place we say the windows will stay in their zones, in the other we say they will move to the zones in the new layout.
The description in the readme it's correct, we need to change the description in the Setting UI.
Something like "Move windows to the zones in the new layout".

[crutkas]

How about: "During zone layout changes, windows assigned to a zone will match new size/position"

[DavidGretzschel]

@crutkas
Well what the hell is the new size/position?
What if the window in th old layout occupies space in two/three/four new different zones?
Does the top-left pixel count?
The top-right?
Is there a hidden numbering-scheme?
What if there's not a zone that it overlaps with or is included in?
If there's a zone X of the identical size and position, do I know that any Window in Zone X will not be moved?
What if five windows from the old layout each in their own zone are all in the area of one zone in the new layout?

The setting doesn't make sense on a deep fundamental level, since it assumes that there is an obvious new position for a window to be assigned to. Fundamentally the setting should be called:
"click me to get random undefined behaviour during layout-change"
Without for example having numbered zones (visible numbers in the editor as well as during dragging, please) and documented behaviour for what happens when the new layout has fewer/more Zones this feature is basically trash and should be removed.

here's a video to elaborate on that point:
https://www.loom.com/share/6360c893dc584664bbc25a610e32dde3

Well in that video I wasn't making the case well. The feature kinda works with few zones.
(and I've tested the feature a bit before, so I could predict reasonably well the effects)

I haven't been using PowerToys, cause I'm only on my FHD-monitor at the moment and there it's more trouble than it's worth. So I don't have realistic 4k-scenarios at the ready, so I exaggerated slightly, but here you can see the predictability-problem a lot better. When I do use FanczZones I have around six to eight Zones, as well as layouts with a only three Zones and I switch between them quite frequently, though. The more I use FancyZones the more Zones I make.
If I had a 42 inch 4k monitor instead of only a 27-inch one, I'd easily have a dozen or more Zones.

https://www.loom.com/share/c150941d10104ab186440f581565c55f

As for the title I'd suggest:
"during layout-change move all windows in Zone X to it's corresponding Zone X in the new layout, if available"
So that would imply that windows assigned to Zone K with K> number of zones of the new layout don't get moved at all. Which would be predictable and sensible behaviour.
And then make those numbers visible in the editor and during the assignment overlay.
The numbers should also flash briefly when moving a window between zones during with the windows+right/left snap command.

[crutkas]

I'm a bit concerned on verbosity of language which is why i had the shorter language. For both translation and non-native english speakers, simpler the better.

Your second video actually raises a good point. i do believe we need to revisit the editor experience and this should be a great item to be included. I feel like #244 is that tracking issue.

I'm a bit confused here watching the first video. You're copying data between two apps, what does this have to do with this current scenario. I'm sadly missing what you're trying to describe.

[DavidGretzschel]

@crutkas
ohhh.... I'm terrribly sorry about that. I have made hundreds of videos in Loom. Mostly for betatesting TheBrain 11 (an unrelated software). First time I have mixed them up.
This is the video I meant to show you.
https://www.loom.com/share/6360c893dc584664bbc25a610e32dde3

[crutkas]

To me, this shows same issue i discussed to make scenarios like this for the editor be much more crisp. I think another thing we could do is validate if we have the telemetry to determine how many people are doing the scenario you're describing and constantly changing their layout. Lets verify how serious of an issue this truly is.

[DavidGretzschel]

I don't mind telemetry, but I guess people that be using a program to the bone and people who are too privacy conscious for allowing telemetry might have an unfortunate overlap.
Most people who already know the potential of software like this have some i3-experience and probably long beards :)
I'd suggest a "build it and they'll come"-approach instead.

[DavidGretzschel]

@crutkas
There's also a hen-egg problem there. At the moment there's no proper keyboard support. People who use Vim and i3 and think everything else is trash, won't have the patience to switch between a dozen layout, if it can't be done fast.
I can do it on a good day, but whenever I have to touch the mouse, I can feel how dopamine is wasted and it's not fun. It's like riding a racing bike downhill, but having to stop every 500 metres for a traffic light.

[crutkas]

I think this would be a great new issue to discuss. This issue is related to verbiage, not fast swapping of layouts. I think it would be a great thing to think about for FancyZone Editor v2

[DavidGretzschel]

yeah, it's a bit off-track, but those things are interconnected.
The more layouts you have, the faster you'd want to swap between them.
And your assumption from what I understood was that you'd have to have a fairly large number of layouts with many windows to encounter this issue in the first place.
[from what I understand, at least]

But assuming that, without at least tweak 3 implemented, the forced mouse-use will discourage any such user to really get into it and encounter such problems:
#769

--
Though this assumption is wrong, I believe. I actually just encountered this issue in real life usage and it's not required to have a layout with an abnormal amount of windows.
[making the video now...]

[DavidGretzschel]

uhm.... you mean that fast-swapping of layouts should be discussed in the Editor v2-thread or that Telemetry should?
I don't see how fast-swapping is related to the Editor.

edit: Ah gotcha. Added the numbering-thing to the Editor v2-thread.
#1032