PowerToys/doc/devdocs
Tudor Croitoru 602368f6cc
[PTRun]New plugin: Value generator with hashing functions (#26097)
* Add hashing plugin for Run

* Cleanup logic for hasher plugin

- The IComputeRequest interface should make it easier to implement new
  generators in the future
- The GUID generator can now generate all versions of GUID (a.k.a. UUID)
- The input for the hash functions is not quite right. The
  Wox.Plugin.Query class doesn't actually have a way to ge the raw query
  as given by the user. The issue is with multiple spaces. An input like
  "a a  a    a    a" would only be accessible as "a a a a a" using the
  Query class.
  So for now, hashing only works correctly if the input
  doesn't contain multiple consecutive spaces.
- Need a way to make clear the usage for generating GUIDv3 and v5, since
  they take 2 parameters. There are defaults, but they aren't very
  clear.

* Change plugin name to ValueGenerator

* Clean up error handling for the input parser

* Add result type and description to subtitle

* Change the icons

* Add Base64 encoding and unit tests

This commit adds Base64 encoding as a utility of the value generator
plugin. The command is `# base64 ***input***`.

Also added unit tests for the UUID/GUID generator and for the input
parser. I don't think tests are necessary for the hashing functions
or for the base64 encoder, since those were part of the the system
libraries.

I'll open a PR for the documentation tomorrow and mark this draft
for review.

* Excluded UUIDv2

* Change icons

* Add RawUserQuery to Wox.Plugin.Query

Getting the RawUserQuery is necessary to be able to handle queries like
`# md5 a    a`, where the intent is to get the hash for `a    a`.
The existing `RawQuery` removes consecutive whitespaces and there was no
other way of getting the request as entered by the user.

* Add ValueGenerator plugin to installer

Also add the unit tests for the plugin to the pipeline.

* Small cleanup

* Fix spelling

* Fix spelling again

* Spell check for guiddata

* More fixes

This commit adds the dev docs explaining the classes in the new plugin.
It also fixes the following issues:
1. ValueGenerator was not a dependency for the PowerLauncher project
2. The error message for an invalid SHA variant now displays the
   supported SHA variants
3. Hash requests now wait for a string to hash (i.e. no longer hash an
   empty string)
4. GUID v3 and v5 namespace aliases allow lowercase notation
5. Unnecessary debug logs
6. An empty query will now just log "Empty request"
7. An invalid query will also log user query

* Spell check fix again

* Change error message for unsupported GUID versions

* Remove Any CPU from the solution

* Add to installer

* Remove duplicated ValueGeneratorPluginFolder entry
2023-07-18 10:44:02 +01:00
..
modules [PTRun]New plugin: Value generator with hashing functions (#26097) 2023-07-18 10:44:02 +01:00
settingsv2 [Docs]Replace docs.micrososft.com with learn.microsoft.com (#20662) 2022-09-28 17:18:55 +01:00
tools Add devdocs for tools (#24903) 2023-03-24 11:38:42 +01:00
akaLinks.md [Docs]Replace docs.micrososft.com with learn.microsoft.com (#20662) 2022-09-28 17:18:55 +01:00
common.md [Docs]Replace docs.micrososft.com with learn.microsoft.com (#20662) 2022-09-28 17:18:55 +01:00
disk-usage-footprint.md [devdocs] Add disk usage footprint doc (#23248) 2023-01-25 18:36:25 +01:00
embedded-msix.md [Docs] Add msix embedding instructions (#13489) 2021-09-30 14:29:05 +03:00
guidance.md [Docs]Replace docs.micrososft.com with learn.microsoft.com (#20662) 2022-09-28 17:18:55 +01:00
localization.md [Docs]Replace docs.micrososft.com with learn.microsoft.com (#20662) 2022-09-28 17:18:55 +01:00
logging.md Centralize c# logger (#22760) 2023-03-21 10:27:29 +01:00
readme.md Devdocs: Fix dead link to settings spec (#25226) 2023-04-06 12:33:06 -07:00
run-as-admin-detection.md Create run-as-admin-detection.md 2020-07-29 17:43:43 -07:00
runner.md [Docs]Replace docs.micrososft.com with learn.microsoft.com (#20662) 2022-09-28 17:18:55 +01:00
style.md Prepare for renaming master -> main (#13235) 2021-11-01 12:21:47 -05:00

Dev Documentation

Fork, Clone, Branch and Create your PR

Once you've discussed your proposed feature/fix/etc. with a team member, and you've agreed an approach or a spec has been written and approved, it's time to start development:

  1. Fork the repo if you haven't already
  2. Clone your fork locally
  3. Create & push a feature branch
  4. Create a Draft Pull Request (PR)
  5. Work on your changes

Rules

  • Follow the pattern of what you already see in the code.
  • Coding style.
  • Try to package new ideas/components into libraries that have nicely defined interfaces.
  • Package new ideas into classes or refactor existing ideas into a class as you extend.
  • When adding new classes/methods/changing existing code: add new unit tests or update the existing tests.

GitHub Workflow

  • 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 a Cost-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 started to 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 that 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, use Rebase 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 the In progress label and if the issue is assigned to a project, move the item to the Done 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).

Compiling PowerToys

Prerequisites for Compiling PowerToys

  1. Windows 10 April 2018 Update (version 1803) or newer
  2. Visual Studio Community/Professional/Enterprise 2022 17.4 or newer
  3. Git clone PowerToys repository
  4. Open the PowerToys.sln file.
  5. If you see a dialog that says install extra components in the solution explorer pane, click install

Get Submodules to compile

We have submodules that need to be initialized before you can compile most parts of PowerToys. This should be a one time step.

  1. Open a terminal
  2. Navigate to the folder you cloned PowerToys to.
  3. Run git submodule update --init --recursive

Compiling Source Code

  • Open PowerToys.sln in Visual Studio, in the Solutions Configuration drop-down menu select Release or Debug, from the Build menu choose Build Solution.
  • 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.

Compile the installer

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, step 1 and 2 must be done before the MSI will be able to be compiled.

  1. Compile PowerToys.sln. Instructions are listed above.
  2. Compile BugReportTool.sln tool. Path from root: tools\BugReportTool\BugReportTool.sln (details listed below)
  3. Compile WebcamReportTool.sln tool. Path from root: tools\WebcamReportTool\WebcamReportTool.sln (details listed below)
  4. Compile StylesReportTool.sln tool. Path from root: tools\StylesReportTool\StylesReportTool.sln (details listed below)
  5. Compile PowerToysSetup.sln Path from root: installer\PowerToysSetup.sln (details listed below)

Prerequisites for building the MSI installer

  1. Install the WiX Toolset Visual Studio 2022 Extension.
  2. Install the WiX Toolset build tools. (installer direct link)
  3. Download WiX binaries and extract wix.targets to C:\Program Files (x86)\WiX Toolset v3.14.

Locally building the installer prerequisite projects all at once from the command-line

  1. Open a Developer Command Prompt for VS 2022
  2. Ensure nuget.exe is in your %path%
  3. 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

Locally compiling the Bug reporting tool

  1. Open tools\BugReportTool\BugReportTool.sln
  2. In Visual Studio, in the Solutions Configuration drop-down menu select Release
  3. From the Build menu, choose Build Solution.

Locally compiling the Webcam reporting tool

  1. Open tools\WebcamReportTool\WebcamReportTool.sln
  2. In Visual Studio, in the Solutions Configuration drop-down menu select Release
  3. From the Build menu, choose Build Solution.

Locally compiling the Window styles reporting tool

  1. Open tools\StylesReportTool\StylesReportTool.sln
  2. In Visual Studio, in the Solutions Configuration drop-down menu select Release
  3. From the Build menu, choose Build Solution.

Locally compiling the installer

  1. Open installer\PowerToysSetup.sln
  2. In Visual Studio, in the Solutions Configuration drop-down menu select Release
  3. From the Build menu choose Build Solution.

The resulting PowerToysSetup.msi installer will be available in the installer\PowerToysSetup\x64\Release\ folder.

Supported arguments for the .EXE Bootstrapper installer

Head over to the wiki to see the [full list of supported installer arguments][installerArgWiki].

Debugging

The following configuration issue only applies if the user is a member of the Administrators group.

Some PowerToys modules require being 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 be 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.

To run and debug PowerToys from Visual Studio when the user is a member of the Administrators group, Visual Studio has to be started with elevated privileges. 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'), save the changes.

How to create new PowerToys

See the instructions on how to install the PowerToys Module project template.
Specifications for the PowerToys settings API.

Implementation details

Runner

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.

Image of the tray icon

Interface

Definition of the interface used by the runner to manage the PowerToys. All PowerToys must implement this interface.

Common

The common lib, as the name suggests, contains code shared by multiple PowerToys components and modules, e.g. json parsing and IPC primitives.

Settings

Settings v2 is our current settings implementation. Please head over to the dev docs that goes into the current settings system.