* Removed and runs
Still needs some extra cleanup and addressing open issues
* Removed and runs
Still needs some extra cleanup and addressing open issues
* Clean
* Update
Unifies the way windows are considered "interesting" by FancyZone.
Berfore the change WinKey + arrows would use different method than
dragging. This PR makes both use the WinKey + arrows method.
Cleans up FancyZones Settings.cpp by removing m_configStrings variable.
Contrary to its name it was used to create color picker control.
Adds a multiline option to the text input to settings. Uses this to
provide the user with a way to exclude certain apps from snapping to
zones.
* Use DPIAware::DEFAULT_DPI
* Make runner DPI-unaware, since it doesn't need to use a Per Monitor V2 DPI.
* Programmatically enable "Per Monitor V2 DPI" for the runner proccess and use a separate DPI-unaware thread for the corresponding API calls
* Increase PCH memory limit for settings project
* Address review issues
* Draw zoneWindows properly scaled
don't exit when clicking on "Apply" if no layout is selected
Credit to @AlexR3 for the fix. Alex provided a more extensive fix that disable the button when no layout is selected, but it requires more changes to the XAML and we preferred to avoid that now.
* Don't trace event on exit
change 'PowertoyModuleDeleter' to not call 'module->disable();' before 'module->destroy();' so the module can distinguish between being turned off and PowerToys exiting.
Code formatting.
* uppercase for event name
* Trace on/off event for ShortcutGuide module
* Trace the 'hide' event only if the guide was visible
'on_hide()' is invoked when the module is turned off, in that case don't trace the hide event.
* Remove spaces in data field names
Remove 'ShowGuide' event since it's not providing any useful data.
* Include build number in version number
the screen. Previously, it would iterate through the zones in the order
they were added and find the first one that fit the description. While
this works in most cases, if a user wants to have overlapping zones, it
is better to iterate through all of them and find the zone that the user
expects. There are cases where a zone is completely inaccessible on drag
because of the current code. To resolve this, the zone search will look
for the smallest zone possible. The reason I chose this solution is
because this guarantees that zones are at least reachable since if a
zone was bigger than another zone, then there must be a part of it
that is exposed, therefore reachable itself. Note: this solution is for
the scenario between two zones. More than that is not guaranteed. But I
feel like this covers enough scenarios to warrant its addition.
Example:
----------------
- Zone1 -
- ---------- -
- - Zone2 - -
- - - -
- ---------- -
----------------
Previously, zone2 was inaccessible since it would iterate through 1 then
2. But 1 would always be seen first when dragging a window. With this
fix it zone2 will be accessible.
Co-authored-by: Alexis Campailla <alexis@janeasystems.com>
Co-authored-by: Bret Anderson <bretan@microsoft.com>
Co-authored-by: Enrico Giordani <enrico.giordani@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Jeff Bogdan <jeffbog@microsoft.com>
Co-authored-by: March Rogers <marchr@microsoft.com>
Co-authored-by: Mike Harsh <mharsh@microsoft.com>
Co-authored-by: Nachum Bundak <Nachum.Bundak@microsoft.com>
Co-authored-by: Oliver Jones <ojones@microsoft.com>
Co-authored-by: Patrick Little <plittle@microsoft.com>
