mirror of
https://github.com/microsoft/PowerToys.git
synced 2025-12-10 17:52:20 -06:00
## Summary of the Pull Request - #39572 updated check-spelling but ignored: > 🐣 Breaking Changes [Code Scanning action requires a Code Scanning Ruleset](https://github.com/check-spelling/check-spelling/wiki/Breaking-Change:-Code-Scanning-action-requires-a-Code-Scanning-Ruleset) If you use SARIF reporting, then instead of the workflow yielding an ❌ when it fails, it will rely on [github-advanced-security 🤖](https://github.com/apps/github-advanced-security) to report the failure. You will need to adjust your checks for PRs. This means that check-spelling hasn't been properly doing its job 😦. I'm sorry, I should have pushed a thing to this repo earlier,... Anyway, as with most refreshes, this comes with a number of fixes, some are fixes for typos that snuck in before the 0.0.25 upgrade, some are for things that snuck in after, some are based on new rules in spell-check-this, and some are hand written patterns based on running through this repository a few times. About the 🐣 **breaking change**: someone needs to create a ruleset for this repository (see [Code Scanning action requires a Code Scanning Ruleset: Sample ruleset ](https://github.com/check-spelling/check-spelling/wiki/Breaking-Change:-Code-Scanning-action-requires-a-Code-Scanning-Ruleset#sample-ruleset)). The alternative to adding a ruleset is to change the condition to not use sarif for this repository. In general, I think the github integration from sarif is prettier/more helpful, so I think that it's the better choice. You can see an example of it working in: - https://github.com/check-spelling-sandbox/PowerToys/pull/23 --------- Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Dustin L. Howett <dustin@howett.net>
8.4 KiB
8.4 KiB
Window Walker plugin
The window walker plugin matches the user entered query with the open windows on the system. The user can switch to the found windows, close them or kill their process.
Remarks
UWP Apps
- The process of an UWP app can't be detected correctly for windows that are minimized while searching. At this time they are assigned to the generic process
ApplicationFrameHost.exe. If the user searches for such a window while it is not minimized, then the process gets assigned correctly/updated.
Killing processes
- Killing the Explorer process is only allowed, if each folder window is running in its own process. (See section
File Explorer settingbelow.) - You can only kill elevated processes, if you have admin permissions (UAC).
- If you kill the process of an UWP app window, you kill all instances of the app. All windows are assigned to the same process.
- Windows of UWP apps don't know their process, until they are searched in non-minimized state.
File Explorer setting
- To kill the Process of an Explorer window, each window has to run in a separate process. Otherwise, the process is the same one as the shell process and killing the shell process will crash the shell (Windows ui).
- To enable this behavior the setting
Launch folder windows in a separate processunderFolder Options > Viewhas to be enabled. - From PowerToys Run you can open the
Folder optionsdialog by clicking the information message in the search results. The information message is only shown when searching with action keyword for explorer windows and can be hidden in the plugin settings. - Note: The folder option/process is evaluated in real time. After changing the setting it is enough to search again for the windows.
Optional plugin settings
- The optional plugin settings are implemented via the
ISettingProviderinterface fromWox.Pluginproject. - All available settings for the plugin are defined in the
WindowWalkerSettingsclass of the plugin. The settings can be accessed everywhere in the plugin code via the static class instanceWindowWalkerSettings.Instance. - We have the following settings that the user can configure to change the behavior of the plugin:
Key Default value Name/Description ResultsFromVisibleDesktopOnlyfalseShow only results from visible desktop SubtitleShowPidfalseShow process id in subtitle SubtitleShowDesktopNametrueShow desktop name in subtitle (If two or more desktops exist) ConfirmKillProcesstrueRequest confirmation when killing a process KillProcessTreefalseKill process and its child processes OpenAfterKillAndClosefalseStay open after closing windows and killing processes (Not working with kill process confirmation) HideKillProcessOnElevatedProcessesfalseHide "kill process" button if additional permissions required HideExplorerSettingInfofalseHide Explorer process information
Technical details
OpenWindows.cs
- The window walker plugin uses the
EnumWindowsfunction to enumerate all the open windows in theOpenWindows.csclass.
SearchController.cs
- The
SearchControllerencapsulates the functions needed to search and find matches. - It is responsible for updating the search text and performing a fuzzy search on all the open windows.
Window.cs
- The
Windowclass represents a specific window and has functions to get the name of the window, the state of the window (whether it is visible or not), theSwitchToWindowfunction which switches the desktop focus to the selected window and theCloseThisWindowfunction which closes the window. TheswitchToWindowaction is performed when the user clicks on a window walker plugin result. - The
Windowclass holds a static cache with the process information of all windows we know so far and each window instance has a property which holds its process information (name, file, ...). The process data in the cache and the window property are of the typeWindowProcess. - To get the desktop information for a window, we use the common
VirtualDesktopHelperinWox.Pluginproject. The instance ofVirtualDesktopHelperis cached in theMainclass of the plugin at runtime. The desktop information is stored in a property of the typeVDesktop.
WindowProcess.cs
- The
WindowProcessclass represents a specific process for a window. - It contains static methods to query process information from the system and instance methods/properties to hold/retrieve the process information we want to know about a window's process.
- Additionally, it contains the method
KillThisProcessto kill the process. (If the user has not enough permissions to kill a process they are requested via UAC.)
ResultHelper.cs
- The
ResultHelperclass contains the code to create the list with all results for PT Run based on the data returned fromSearchControllerclass. - There is a special result that is added if the folder windows doesn't run in separate processes and the user searches for Explorer windows using the action keyword.
- This result informs the user that there is a setting that must be enabled to be able to kill Explorer processes.
- The result can be disabled in plugin options. When it is clicked it opens the folder options.
ContextMenuHelper.cs
- The
ContextMenuHelperclass provides the code for the context menu items.
WindowWalkerSettings.cs
- The
WindowWalkerSettingsclass provides access to all optional plugin settings. - The class has a static property called
Instancethat holds an instance of the class itself. This allows us to access the settings from everywhere in the plugin code without having additional parameters in our methods.
Score
The window walker plugin uses FuzzyMatching to get the matching indices and calculates the score by creating a 2 dimensional array of the window and the query text.
Unit Tests
We have a Unit Test project that executes various test to ensure that the plugin works as expected.
PluginSettingsTests.cs
- The
PluginSettingsTests.csclass contains tests to validate that all settings exist and that they have the correct default values.

