Once you've discussed your proposed feature/fix/etc. with a team member, and an approach or a spec has been written and approved, it's time to start development:
- Fork the repo on GitHub if you haven't already
- Clone your fork locally
- Create a feature branch
- Work on your changes
- Create a Draft Pull Request (PR)
- When ready, mark your PR as "ready for review".
- Follow the pattern of what you already see in the code.
- Coding style.
- Try to package new functionality/components into libraries that have nicely defined interfaces.
- Package new functionality into classes or refactor existing functionality into a class as you extend the code.
- When adding new classes/methods/changing existing code, add new unit tests or update the existing tests.
- Before starting to work on a fix/feature, make sure there is an open issue to track the work.
- Add the
In progress
label to the issue, if not already present. Also add aCost-Small/Medium/Large
estimate and make sure all appropriate labels are set. - If you are a community contributor, you will not be able to add labels to the issue; in that case just add a comment saying that you have started work on the issue and try to give an estimate for the delivery date.
- If the work item has a medium/large cost, using the markdown task list, list each sub item and update the list with a check mark after completing each sub item.
- When opening a PR, follow the PR template.
- When you'd like the team to take a look (even if the work is not yet fully complete) mark the PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
- When the PR is approved, let the owner of the PR merge it. For community contributions, the reviewer who approved the PR can also merge it.
- Use the
Squash and merge
option to merge a PR. If you don't want to squash it because there are logically different commits, useRebase and merge
. - We don't close issues automatically when referenced in a PR, so after the PR is merged:
- mark the issue(s) that the PR solved with the
Resolution-Fix-Committed
label, remove theIn progress
label and if the issue is assigned to a project, move the item to theDone
status. - don't close the issue if it's a bug in the current released version; since users tend to not search for closed issues, we will close the resolved issues when a new version is released.
- if it's not a code fix that effects the end user, the issue can be closed (for example a fix in the build or a code refactoring and so on).
- mark the issue(s) that the PR solved with the
- Windows 10 April 2018 Update (version 1803) or newer
- Visual Studio Community/Professional/Enterprise 2022 17.4 or newer
- A local clone of the PowerToys repository
- Open the
PowerToys.sln
file. - If you see a dialog that says
install extra components
in the solution explorer pane, clickinstall
We have submodules that need to be initialized before you can compile most parts of PowerToys. This should be a one-time step.
- Open a terminal
- Navigate to the folder you cloned PowerToys to.
- Run
git submodule update --init --recursive
- Open
PowerToys.sln
in Visual Studio. - In the
Solutions Configuration
drop-down menu selectRelease
orDebug
. - From the
Build
menu chooseBuild Solution
, or press Control+Shift+b on your keyboard. - The build process may take several minutes depending on your computer's performance. Once it completes, the PowerToys binaries will be in your repo under
x64\Release\
.- You can run
x64\Release\PowerToys.exe
directly without installing PowerToys, but some modules (i.e. PowerRename, ImageResizer, File Explorer extension etc.) will not be available unless you also build the installer and install PowerToys.
- You can run
Our installer is two parts, an EXE and an MSI. The EXE (Bootstrapper) contains the MSI and handles more complex installation logic.
- The EXE installs all prerequisites and installs PowerToys via the MSI. It has additional features such as the installation flags (see below).
- The MSI installs the PowerToys binaries.
The installer can only be compiled in Release
mode; steps 1 and 2 must be performed before the MSI can be compiled.
- Compile
PowerToys.sln
. Instructions are listed above. - Compile
BugReportTool.sln
tool. Path from root:tools\BugReportTool\BugReportTool.sln
(details listed below) - Compile
WebcamReportTool.sln
tool. Path from root:tools\WebcamReportTool\WebcamReportTool.sln
(details listed below) - Compile
StylesReportTool.sln
tool. Path from root:tools\StylesReportTool\StylesReportTool.sln
(details listed below) - Compile
PowerToysSetup.sln
Path from root:installer\PowerToysSetup.sln
(details listed below)
- Install the WiX Toolset Visual Studio 2022 Extension.
- Install the WiX Toolset build tools. (installer direct link)
- Download WiX binaries and extract
wix.targets
toC:\Program Files (x86)\WiX Toolset v3.14
.
- From the start menu, open a
Developer Command Prompt for VS 2022
- Ensure
nuget.exe
is in your%path%
- In the repo root, run these commands:
nuget restore .\tools\BugReportTool\BugReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\BugReportTool\BugReportTool.sln
nuget restore .\tools\WebcamReportTool\WebcamReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\WebcamReportTool\WebcamReportTool.sln
nuget restore .\tools\StylesReportTool\StylesReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\StylesReportTool\StylesReportTool.sln
If you prefer, you can alternatively build prerequisite projects for the installer using the Visual Studio UI.
- Open
tools\BugReportTool\BugReportTool.sln
- In Visual Studio, in the
Solutions Configuration
drop-down menu selectRelease
- From the
Build
menu, chooseBuild Solution
. - Open
tools\WebcamReportTool\WebcamReportTool.sln
- In Visual Studio, in the
Solutions Configuration
drop-down menu selectRelease
- From the
Build
menu, chooseBuild Solution
. - Open
tools\StylesReportTool\StylesReportTool.sln
- In Visual Studio, in the
Solutions Configuration
drop-down menu selectRelease
- From the
Build
menu, chooseBuild Solution
.
- Open
installer\PowerToysSetup.sln
- In Visual Studio, in the
Solutions Configuration
drop-down menu selectRelease
- From the
Build
menu chooseBuild Solution
.
The resulting PowerToysSetup.msi
installer will be available in the installer\PowerToysSetup\x64\Release\
folder.
Head over to the wiki to see the [full list of supported installer arguments][installerArgWiki].
To debug the PowerToys application in Visual Studio, set the runner
project as your start-up project, then start the debugger.
Some PowerToys modules must be run with the highest permission level if the current user is a member of the Administrators group. The highest permission level is required to be able to perform some actions when an elevated application (e.g. Task Manager) is in the foreground or is the target of an action. Without elevated privileges some PowerToys modules will still work but with some limitations:
- The
FancyZones
module will not be able to move an elevated window to a zone. - The
Shortcut Guide
module will not appear if the foreground window belongs to an elevated application.
Therefore, it is recommended to run Visual Studio with elevated privileges when debugging these scenarios. If you want to avoid running Visual Studio with elevated privileges and don't mind the limitations described above, you can do the following: open the runner
project properties and navigate to the Linker -> Manifest File
settings, edit the UAC Execution Level
property and change it from highestAvailable (level='highestAvailable')
to `asInvoker (/level='asInvoker').
See the instructions on how to install the PowerToys Module project template.
Specifications for the PowerToys settings API.
The PowerToys Runner contains the project for the PowerToys.exe executable. It's responsible for:
- Loading the individual PowerToys modules.
- Passing registered events to the PowerToys.
- Showing a system tray icon to manage the PowerToys.
- Bridging between the PowerToys modules and the Settings editor.
The definition of the interface used by the runner
to manage the PowerToys. All PowerToys must implement this interface.
The common lib, as the name suggests, contains code shared by multiple PowerToys components and modules, e.g. json parsing and IPC primitives.
Settings v2 is our current settings implementation. Please head over to the dev docs that describe the current settings system.