Auto-generated ("scalable") WPF GUI

[couleurm]

trafficstars

Is your feature request related to a problem?

Having to manually modify the GUI to add something new (e.g a new app to the installer's section) when you could have have structured data, like one big hashtable with each value for an app being @{DisplayName = "official.winget.PackageName"}, it could also be equal to a hashtable which contains stuff like tooltips, package names..). It could also be used to store scriptblock that contains tweaks

Also throwing that out there: you could have sections for common apps for each known package managers (Chocolatey, Scoop, Winget) and it'd be much easier making something like this by doing the following:

Describe the solution you'd like

I'm a WPF noob, so consider this with a grain of salt (I'd love helping out and learning more 👍)

The honest reason I'm making this issue is because I'm struggling with a clunky WPF function of mine I've frankensteined to make work (from farag2's Sophia Script). I've turned into a neat and user-friendly selector I can use within my scripts to prompt users, and helping you making it more useable (and maybe also useable outside of winutil for my usecase) would also help me:

It loops over each objects you pass to it (via -Items) in order to generate the GUI, it's logic may be interesting to implement into winutil to make it simpler to add new features

Here's the code for Invoke-Checkbox and a video demonstrating it:

https://user-images.githubusercontent.com/82747632/204089651-6bea07b5-fed4-470e-84b6-a10714d63f34.mp4

(didn't show it here but yes you can tick multiple checkboxes and it'll return them like you'd expect it to)

[DeveloperDurp]

I 100% agree, only downside is in the end we would still want to load the GUI from a static file as there is a performance hit. I support a powershell GUI at my day job which dynamically builds the GUI and it can take several seconds to finish depending on how much it's doing. I am not WPF expert either but I like the idea, I think the best way would be to do something similar to how the helper script is setup.

https://github.com/ChrisTitusTech/winutil/blob/main/config/helperscript.ps1

[couleurm]

If it's slow to run it could be compiled into a static state with CI, kinda like Hugo?

Edit: we could also format the XAML string with the content, e.g with $($Apps | ForEach-Object{("`t" * 2) + $_.Display_Name}

[DeveloperDurp]

Yeah, that's kinda what I was alluding to. Only thing is we would want to keep in mind when people are developing locally IE #428 so additions should also be able to be ran manually.

[ChrisTitusTech]

@couleurm Thanks for this idea, I'm sure we will find a spot to utilize it and generate maybe an uninstall or install prompt I'm thinking.

WPF is definitely limiting, but I really like the code all being open including the GUI where no one has to compile the project or run an executable. There was a really neat toggle button someone did as a commit, that I had no idea WPF even had, so there is still a lot of room for us to grow in the GUI realm.

[DeveloperDurp]

@ChrisTitusTech in theory we should be able to do anything a .net project can do inside of powershell with modifications. IE Something like this project https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit

Though at some point we are trying to force a square peg into a round hole.