Hi @denelon. I started working on this module with quite some hiccups. Despite the hiccups, working with the low-level APIs was an interesting learning curve, and I guess the engineers in your team will like it as well. I aimed to address the logoff/login for users when applying a DSC resource. There might only be 1 or 2 at the moment because it didn't have a clear function to call (it's in a TODO).

Unfortunately, I couldn't finish the Touchpad class. I already constructed the function with the C/C++ code, but somehow, I cannot get it to work. Hopefully, someone on the team can help me with it.

Hi @Gijsreyn,

Apologies for experimenting with your module instead of one of my own. In reviewing your very well-formatted code, I kept seeing the code patterns stand out and wanted to express them in a more compact way. Please let me know what you think.

Hey @stephengillie, thanks for hopping in. Yes, that's what I noticed as well, and I didn't really like it. There's so much overlap in each module, and Demitrius mentioned one sentence back about having the modules move toward the DSC community. That sentence remained with me.

Having said that, I had some time spent investigating the class-based development within the DSC community. It was a bit tough to get started, but I finally managed to get a mock setup, and I feel it's a way better approach with modularity included. I demoed this during the last community call as a sneak peek, and I intend to move most of the content that I have PRed here to that module.

image

Basically, the 010.SettingsBase.ps1 contains a class that can be inherited across (nearly) all settings unless they don't contain 0 or 1 values as DWORDS (still thinking about it to expand). Others can be more self-contained.

The repository is still private, but if you and @denelon want access to it, just give me a heads-up. I'm just letting you know that I'll not spend much time around this repository, and I guess most PRs can be abandoned.

Lastly, on the touchpad settings. Thanks for the deep dive and yes, I think I noticed these settings also. The thing is, you can change them in the registry, but the user would still have to log out and log back in. That's why I wanted to use the API to get the values and set it using that. Anyway, if you've someone internal who might be able to help out, that would be pretty cool :)

@Gijsreyn one thing to note about my comment is that the "Microsoft" specific resources wouldn't be in scope to move to the DSC Community. Several folks have expressed concerns about digitally signed modules. In order for the Microsoft resources to be signed by Microsoft, they need to come from a Microsoft maintained project.

@Gijsreyn one thing to note about my comment is that the "Microsoft" specific resources wouldn't be in scope to move to the DSC Community. Several folks have expressed concerns about digitally signed modules. In order for the Microsoft resources to be signed by Microsoft, they need to come from a Microsoft maintained project.

Auch, then I'm feeling a bit stuck here, and I'm not sure how to contribute further. I guess that's about 70% to 80% of the modules here. The only ones that would probably participate are Python, Npm, etc. I still want to contribute and especially bring in some professionalization and standardization in here @denelon , as Stephen also mentioned. Yet, the approach is vague for me what the best way would be. I can hit up the sources that I've created for the community in this repository to get all the sweetness from the community in here if that's desirable. That only would require the pipeline to be adjusted.

Yes, and @AmelBawa-msft is looking at the pipelines so we can iterate a bit more quickly here.

@denelon Do note, when the module is built through Sampler, it also includes the DscResource.Base and DscResource.Common. Is that something we want to sign during packaging?

image

If it's coming out of the "build" from this project, it's likely we will need/want to sign.

Alright, I'll try to hit something up hopefully this weekend.