Powertoys: [FZ Editor] new zone added in a custom layout can be unreachable

[SeraphimaZ]

Create a custom layout, add new zones.

Expected behavior: new zones will always be on screen.

Actual behavior: zones start to be partially of screen and can be fully off screen.

[crutkas]

how many is "many"? 10? 100?

[enricogior]

how many is "many"? 10? 100?

It depends on the screen size, it can be just 3.

[crutkas]

The title / description for this is super vague.

what is 'unreachable'
Is this canvas? grid style?
what is the repo?
screenshots?

[enricogior]

Updated title and description.

[chenac64]

Working on a fix for this but wanted some clarification on what the intended behavior is if the zones become unreachable. Should the generated ones start shifted diagonally? On top of each other eventually?

[crutkas]

@chenac64 / @SeraphimaZ How does one reproduce the bug?

Is this relevant to only the focus layout? I can't repro

[chenac64]

This is an example of it in the custom layout but I can reproduce it similarly on the focus layout.

[ColdTune]

Regarding chenac64's post above, there is no warning that notifies users once new zones are off-screen.

[enricogior]

@chenac64

Should the generated ones start shifted diagonally? On top of each other eventually?

Use a very small delta for the diagonal shift.
Somewhere we have a hard-coded limit that I think is 64, so if showing 64 will require to be on top of each other that's fine.
Thanks.

[crutkas]

@chenac64 thanks for visual, i didn't try that path and now understand.

1. Make default zone smaller

Suggested solution: Don't do the shift, they should be in dead center overlapping. Adding in a new zone always is on top.

Why: there will always be someone with a small enough monitor where they will hit this case and someone with a large enough monitor where they will want endless numbers of zones

[ColdTune]

Implementation 1:

Implementation 2:

@crutkas Just to make sure, what you are looking for is implementation 1?

[enricogior]

@crutkas

they should be in dead center overlapping

In that case we need to make sure the zone is not covered by the Editor dialog.
Also since the number is centered in the zone, it is covered by the Editor dialog, not ideal, we may reconsider to place the Editor dialog in a different position so it won't interfere.

[chenac64]

something like this?

[crutkas]

something like this?

@chenac64 Yup.

@enricogior I just can’t think of a better way. A user can delete the zones if they have too many.

[enricogior]

@crutkas @chenac64
I have to be honest here, I don't like the zones being added on top of each other.
A small shift (horizontally and vertically) is a better choice.
When a new zones would be partially outside of the screen, simply restart the process from the same coordinates.

[crutkas]

i'm not opposed to that, just repeat the focus style grid, smaller / tighter. When it would fall off screen, then do overlap.

Correct?

[chenac64]

It would look like @ColdTune implementation 2? with smaller delta?

[crutkas]

Yes but Honestly seems odd it starts in center and does the diagonal motion

On repeat I would start upper left then and move down vs center.

This is an edge case scenario

[enricogior]

@crutkas

I'm not opposed to that, just repeat the focus style grid, smaller / tighter. When it would fall off screen, then do overlap.
Correct?

Yes.

On repeat I would start upper left then and move down vs center.

Agreed.

[crutkas]

@chenac64 / @ColdTune does that make sense? Seems like everyone is in agreement now for behavior

[chenac64]

I think we understand the changes that need to be made and will try and submit a PR for the issue