[FZ Editor] allow manual coordinates (absolute and relative)

[PaulCoddington]

Summary of the new feature/enhancement

Sizing of custom zones in editor by dragging mouse is a little bit coarse (hit and miss) in terms of getting close to edges of screen symmetrically and allowing window edges of multiple zones to line up neatly. Some possible solutions are suggested for consideration.

Proposed technical implementation details (optional)

1. Perhaps have an option for the editor to snap to a grid of user specified n pixels.

2. Perhaps have optional ability to input window dimension and position directly in both absolute terms (n x n pixels) and in terms of percentage of screen width and height.

[mikeroygray]

Agreed. Note: Obviously, the numbers in question ARE actually stored somewhere already - either in a settings file or in the registry. So, maybe we can edit them directly. I spent a while looking but couldn't figure out where - can anyone help out here?

[TheMrJukes]

When you apply a layout from the editor to the engine, the editor calls PersistZoneSet. It passes a bunch of data back including an array of ints which represent the zones. PersistZoneSet creates a new ZoneSet from the data and then calls ZoneSet::Save. That basically writes a ZoneSetPersistedData binary blob to the registry at HKCU\Software\SuperFancyZones\MonitorWidth_MonitorHeight. MonitorWidth_MonitorHeight being the resolution of the monitor you are configuring.
An issue #368 has been opened to look at storing the data in a more friendly json format which I 100% agree with and could more easily allow sharing of cool layouts.

[mikeroygray]

Huh! Well, I found the entry in question - but my Hex-fu being what is(n't), I think I'll wait for that json!

[JWohlgem]

This would be really nice. Perhaps consider displaying the width x height, and potentially x,y coordinates of one of it's corners when editing customs zones would go a long way to improving this. Editing registry data should likely be a last resort.

[enricogior]

Hi @JWohlgem
there is an issue for tracking the "display coordinates/size" of the zones while editing #524
Feel free to up-vote/add you comments there.
Thank you.

[christiandull]

It is hard to get the zone to the correct position and correct size with the mouse.

It would be great if we get a edit button left of the close button. There i want to put in the position (x pos, y pos) and the size (width, height) - like in the program WindowManager.

Also it would be great if there is a grab/pick button, where i can choose a existing window to get the coordinates from it.

And also that i can setup a shortcut for this zone (like Ctrl+Alt+F1) to send the active window directly to this zone without mouse

And it would be also great, if i can see and setup there the position nr. of the zone (the dots you see when you drag a window with shift).

[spackmat]

In the meantime for those, who are looking for the config file to edit the custom zone dimensions manually, here it is: %LocalAppData%\Microsoft\PowerToys\FancyZones\zones-settings.json

[IAmIlliest]

In the meantime for those, who are looking for the config file to edit the custom zone dimensions manually, here it is: %LocalAppData%\Microsoft\PowerToys\FancyZones\zones-settings.json

As mentioned in this thread:
#17998 (comment)

I don't see the zones-settings.json file in that path (but have the other fancy zone settings there). Any ideas, is it possible that if one got to this point from older versions, that it still relies on the reg keys to store such information or something like that, and hence hasn't created the zone-settings.json file?

[SeraphimaZykova]

In the latest versions zones-settings.json was replaced with other files. You can find your layouts in the %LocalAppData%\Microsoft\PowerToys\FancyZones\custom-layouts.json.

[Jay-o-Way]

Any (rough) e.t.a. perhaps?

[cloudrootab]

Being able to type in the dimensions would make things alot easier. But please make it accessible via the GUI.

[wolfensteinjd]

Dear Sirs,
Please allow this enhancement. That is all.

[WimSKW]

I'm in favour of making both entry by pixels and entry by percentage possible.
However, when choosing one or the other, that choice should be saved in the json file, together with the exact values to avoid the rounding errors that I observe today in v.0.64.1.
I have three 1280x1024 monitors connected to a Matrox TrippleHead2Go which is connected to the graphics card. My computer sees this "Matrox-monitor" as being 3840x1024. I created a layout with 3 zones (one row and three columns) to match the physical monitors. The layout editor correctly shows every zone as being 1280x1024. However, when I snap a window to zone 2 to be fullscreen on monitor 2, the leftmost one-pixel column of the window is visible on monitor 1.
The json saves: "columns-percentage": [3333, 3333, 3334]. So while 33.33% of 3840 is 1279.872, FancyZones apparently incorrectly rounds this to 1279.
For the time being, I worked around it by modifying the json to "columns-percentage": [3334, 3333, 3333].

[Jay-o-Way]

I realized there is another thing we humans use: fractions. Usually that would be converted to percentage, but - as the comment above shows - that is quickly difficult in a base-10 system. One-third can be written as 1/3 (or 4/12 for those who like dozenal) without rounding problems.
Think it would be possible to add fractional notations?

[WimSKW]

A fraction would work but in essence "1/3" is "1 divided by 3" which is equal to 0.33333333333...
Anyway, 1279.827 should be rounded up to 1280 and not down to 1279.
Conversion between percentages and pixels often leads to rounding errors. So let the user select which system to use. Store the exact values the user entered - be it pixels or percentages - and apply those. That way, no conversion is needed.

[Jay-o-Way]

Store the exact values the user entered - be it pixels or percentages - and apply those. That way, no conversion is needed.

Strictly speaking that's contradictory. Display resolutions are well chosen; most can be devided by 2,3,4,5,6,8,9,10,12,15... However, here you still mention percentages and it's just that format that quickly leads to issues. That's why I suggested fractions.