FancyZones - Zone Editor #244
Labels
FancyZones-Editor
Issue revolving the FancyZone Editor
Idea-Enhancement
New feature or request on an existing product
Product-FancyZones
Refers to the FancyZones PowerToy
Comments
|
Closed
|
Upvoting this for #2. I really want to fine-tune the zones. |
|
For #2, a temporary workaround is to attack the registry directly: each custom zone can be found in HKCU/Software/SuperFancyZones/Layouts. If you have a layout of "00 01 00 03 07 80 06 10 01 00 00 00 00 07 80 04 10", it van be read as:
You'll then have four dwords for each zone ("00 00 00 00 07 80 04 10"), that's where you'll want to fine tune: the first four are X & Y coordinates for the upper left corner of the zone : "00 00" and "00 00", obviously are 0 & 0. If you want the zone to start at coordinates 450px/200px, you'll have to convert to hexa: 01 C4 (450) & 00 C8 (200). The second group of four is the size of the zone, once again in hexa: 07 80 = 1920px; 04 10 = 1040px. So if you want a 800x600 zone starting 450 pixels on the left and 200 pixels from the top: 01 C4 00 C8 03 20 02 58. |
|
I'd definitely like to see the ability to fine tune the zones, with magnet snapping/screen coordinates/grid system (aka http://windowgrid.net/) |
|
From #768, have the editor show the zone #'s more clearly. |
crutkas
added
Idea-Enhancement
|
davidegiacometti
pushed a commit
to davidegiacometti/PowerToys
that referenced
this issue
Jan 9, 2025
## Summary of the Pull Request This PR is ready to review with a bunch of code clean-up around shell and page initialization/navigation, progress, errors, and the back button. There's still some future items to think about, but that's beyond the scope of this work right now. See more notes in comments below on changes: > Alright, I cleaned up all the Page Initialization and Navigation code for Shell, it's all centralized there now (which makes sense) and removes 3x duplicated code we had in the ExtPage templates. They're just basic XAML controls now which don't really need to worry about how they get loaded, and just get their VMs. > > I also tidied up the massive if statement we had in ShellPage.xaml.cs for each page type so we have a singular logical flow that just branches in two statements with an inline switch for the VM constructor and the page type. > > In the future, we may want to cache some page VMs there, so if you navigate back/forth we don't reload everything... > > This also let us remove a message which was effectively just internal communication. Should be a bit cleaner now, certainly easier to add new page types now too. These are some of the last remnants of things from the original MVVM setup when we were still testing patterns and then just copied. This uses `IsInitialized` for tracking the progress bar and bubbles up errors better without blocking the app (and provides better context for errors). This also fixes the issue with the Back Button stealing focus instead of the search box (by moving it to the Shell page to leave the SearchBox control as just responsible for the searchbox/keyboard input). ------- Future Open questions/TODO: - [ ] How do we better track the parent extension/owner of pages/commands/etc... for error reporting? - [x] Need to clean-up backend logic of VMs for the loading state for the new Shell page centralization - [x] For instance, progress only happens like once now... - [x] May be able to centralize some of the loading bits logic? - [x] Finalize some brushes for error items - [ ] Still need to potentially track individual issues loading specific items, but maybe this is a good enough start for a single PR once the above are addressed? - [ ] Cache page VMs? - [ ] Clean-up async loading of pages and their content Helps with microsoft#220. This will make microsoft#238 easier as then we don't need as much XAML/Loading glue for those Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Mike Griese <zadjii@gmail.com>
davidegiacometti
pushed a commit
to davidegiacometti/PowerToys
that referenced
this issue
Jan 9, 2025
This subtly regressed in microsoft#244, so subtly that I didn't really notice it till I fixed it. In that PR, we replaced the `visibility` binding of the `ProgressBar` with a binding to `IsInitialized`. For most pages, this actually just works fine - they're only initialized once they return some results. And most pages are only loading until they first return something. But the trick is with pages that do some `Loading` _after_ they're initialized. For them, the progress bar never shows up, because `Initialized` is already true. I actually only stumbled upon this because of a totally different bug (which this also fixes). In rare cases we'd load a little out of order, and the ShellPage would try to determine if it should hide the `ErrorMessage` or not. About 25% of the time, it would evaluate `{x:Bind ViewModel.CurrentPage.ErrorMessage, Converter={StaticResource StringNotEmptyToVisibilityConverter}, Mode=OneWay}` _before_ the `CurrentPage` got set, so it would show it initially. That looked real janky.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'll start with the obvious and very much requested multi-monitor zone editing support.
Users can see that predefined full-monitor zones are present on additional displays but sadly there doesn't seem to be a way for users to customise zones on them.
I would suggest adding a "Choose affected monitor" at the top of the zone editor which will list all available system displays and, depending on the selected display, will allow the user to pick and/or edit the layout to apply to the display.
Adding the ability to fine tune zone sizes by allowing a user to specify the pixel width/height values would be a welcome addition for all those OCD users out there (guilty =P ).
A simple set of integer fields in the middle of each zone to capture width/height values would be perfect (unless you can think of a more elegant solution).
I've noticed that when setting "Space around zones" to "0", the zone edges become completely invisible when clicking "Edit selected layout" (but still have a visual cue with a layout selected prior to entering the editing mode), which make it very difficult to get an idea of what your layout looks like by only relying of the circular blue resizing handles.
Please ensure that the edge visual cue is also visible when editing.
Thank you very much for the already incredible work =)
The text was updated successfully, but these errors were encountered: