Added functionality for General Settings Page

[ghost]

Summary of the Pull Request

• Added functionality for General Settings Page

• Settings Include: Run on startup, change the theme, links to issues and bug reports and restart as admin.

• I would like feedback on the architecture, implementation, and design. I will enforce more good practices on the upcoming PRs.

References

PR Checklist

• Applies to Settings V2 UI Task: General Settings Tab #1482
• CLA signed. If not, go over here and sign the CLA
• [] Tests added/passed
• Requires documentation to be updated
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where a discussion took place: Settings V2 UI Task: General Settings Tab #1482

Detailed Description of the Pull Request / Additional comments

• To test the code, re-add refference to the IPCLib dll found in x64/ directory to the Runner.

Validation Steps Performed

• Validdated output on the UI and the json settings file found in AppData/Local/Microsoft/PowerToys/settings.json

[yuyoyuppe]

LGTM. Out of curiosity, what are the main differences between System.Text.JSON and Json.NET libraries? I've noticed that we use the former one in FZE, while the latter in newer modules.

[crutkas]

LGTM. Out of curiosity, what are the main differences between System.Text.JSON and Json.NET libraries? I've noticed that we use the former one in FZE, while the latter in newer modules.

IMO JSOn.net is far more the standard and is faster. Template studio uses this.

We should standardize across the code base IMO too

[ryanbodrug-microsoft]

System.Text.JSON

LGTM. Out of curiosity, what are the main differences between System.Text.JSON and Json.NET libraries? I've noticed that we use the former one in FZE, while the latter in newer modules.

@laviusmotileng-ms : This is a good call out. If possible we should be using System.Text.JSON. It was built into .net core 3, partly to alleviate issues with dependent packages using conflicting versions of json.net (newtonsoft.json). System.Text.Json claims performance improvements over json.net. With that said, I do not personally have enough experience with System.Text.JSON to say that it is not without some 'gotcha's, but I would recommend it as the default json serializer for new projects.

[ryanbodrug-microsoft]

LGTM. Out of curiosity, what are the main differences between System.Text.JSON and Json.NET libraries? I've noticed that we use the former one in FZE, while the latter in newer modules.

IMO JSOn.net is far more the standard and is faster. Template studio uses this.

We should standardize across the code base IMO too

@crutkas Are we sure that JSON.net is faster? I would actually lean towards System.Text.JSON. Especially if we are looking to standardize across the codebase as it grows. I've been bitten before where I've been unable to use certain packages because of specific version dependencies on json.net. Although, like I said in lavius's comment. I don't have much experience with System.Text.JSON and given that it's relatively new, there still may be dragons.

[crutkas]

Let’s then do the system one. I have always had good experiences. I just think we should standardize across everything.

[ghost]

LGTM. Out of curiosity, what are the main differences between System.Text.JSON and Json.NET libraries? I've noticed that we use the former one in FZE, while the latter in newer modules.

@ryanbodrug-microsoft I tried using the .Net core 3 Json library with no success. The library currently does not support the parsing of dynamic objects. This is an open issue in the .net runtime project. To continue using this will mean that I will have to add class models for each settings file. I am adding that now and will push the changes.

[ryanbodrug-microsoft]

LGTM. Out of curiosity, what are the main differences between System.Text.JSON and Json.NET libraries? I've noticed that we use the former one in FZE, while the latter in newer modules.

@ryanbodrug-microsoft I tried using the .Net core 3 Json library with no success. The library currently does not support the parsing of dynamic objects. This is an open issue in the .net runtime project. To continue using this will mean that I will have to add class models for each settings file. I am adding that now and will push the changes.

I think class models is probably the better way to go anyway. I'd prefer to get a compile error if a setting is accidentally removed instead of a runtime error using dynamic objects. Hopefully this isn't much work.