Integrate keyboard manager with settings v2[Part-2]

[udit3333]

Summary of the Pull Request

Adding Custom Actions to trigger Keyboard Manager module to launch Remap Keyboard and Edit Shortcuts windows.

PR Checklist

• Applies to Keyboard shortcut manager #6
• CLA signed. If not, go over here and sign the CLA

Detailed Description of the Pull Request / Additional comments

1. Added bindings to trigger on button click action on new settings UI.
2. Added logic to allow background runner to launch window on foreground.
3. Updated Keyboard Manager module to launch the Windows on valid Custom Actions.

Validation Steps Performed

Validated locally by launching both Remap Keyboard and Edit Shortcuts window from the settings UI.

[yuyoyuppe]

• I've tried launching Debug version locally, but Settings window doesn't open for me (nothing happens).
• Could you please help me understand why do we need to create separate windows via custom actions instead of showing all settings inside a Settings v2 page?

[udit3333]

• I've tried launching Debug version locally, but Settings window doesn't open for me (nothing happens).

@yuyoyuppe This is an known issue currently with new settings projects I'm adding an Github issue for it now. What is happening the Microsoft.PowerToys.Settings.UI.Runner on building deletes the dependencies dll alternatively . Can you try build the solution again and launch Powertoys from the exe and make sure the output directory of Microsoft.PowerToys.Settings.UI.Runner project x64\Debug\netcoreapp3.1 looks like this:

• Could you please help me understand why do we need to create separate windows via custom actions instead of showing all settings inside a Settings v2 page?

Keyboard Manager UI windows are being implemented on module side mainly because the logic to receive the Key stroke with LowLevelKeyboardHook and interpret the Key stroke as a remapped stroke on UI is implemented in the module.
Adding @arjunbalgovind if I'm missing other reasons.

[yuyoyuppe]

Yep, that helped. We'd like to minimize the pt module interface in the future, so please consider using another mechanism to communicate between settings and the module (preferably via some .json file)

[arjunbalgovind]

LGTM

[udit3333]

Yep, that helped. We'd like to minimize the pt module interface in the future, so please consider using another mechanism to communicate between settings and the module (preferably via some .json file)

Sure I'm currently leveraging the logic implemented in SettingsV2 which uses Ipc to communicate with the modules. As we update the logic for new Settings and modules to communicate with either file based trigger implementation or some other mechanism we can leverage same logic here as well.