#Scripting WinUI 3 with PowerShell

28 messages · Page 1 of 1 (latest)

versed igloo
#

I've just published my new module and I'm looking for feedbacks or someone who can try it out.
https://github.com/mdgrs-mei/WinUIShell

Since it looks like loading WinUI 3 dlls on PowerShell is still hard, I decided to run a standalone process WinUIShell.Server.exe that provides all the UI functionalities. The module just communicates with the server through IPC.

I have 2 concerns with this approach:

  1. Looks like it's running without problems on Windows Sandbox but does bundling an exe file with a module have any pitfalls? I'm imagining anti virus or policy blocking the exe.

  2. There is no typical threading issue (Event handlers blocking the GUI) with this approach. Can you think of any other issue or downside on the other hand?

GitHub
GitHub - mdgrs-mei/WinUIShell: Scripting WinUI 3 with PowerShell

Scripting WinUI 3 with PowerShell. Contribute to mdgrs-mei/WinUIShell development by creating an account on GitHub.

opaque flicker
#

I'm not sure I like the approach, Your inviting more work for yourself taking this route, not only are you are creating a 'shim' for each UI Element, you end up loosing out on complex capabilities these UI Tools have.

For example, you can create data templates with the WindowsApp SDK, where I can populate large swatches of data by binding elements. We wont have that or it will become horribly complex this route.

opaque flicker
#

If you were to continue, I would strongly recommend using a reflection based lookup to see if a type exists and then return a new version of that object. and place it behind a PSCmdlet..

for example: New-WinUIShellElement and use a custom PSCustomObject to act as a gateway between the UI elements and WinUIShell.Server.exe That way it can be programmatically ran/assigned data as an event shim.

This way you have your cake and eat it too dynamically, and it will remain discoverable.

versed igloo
#

Thank you @opaque flicker !
Yes, it's a lot of work to maintain the shim objects and I still need to find a way to add Data Binding. If only there was a robust way to load WinUI 3 assemblies...

#

Adding a cmdlet to create the UI elements might be a good idea as we surely have an issue in discoverability.

opaque flicker
#

Well you can add to discoverability by walking down the class objects reflected by the library, and pull them in when they match its baseobject of uielement... that would add to discoverability.

It would be reflection heavy but its probably a whole lot better than where you are now.

For Adding xaml support it should be pretty easy to do. i got code somewhere in my gists you can peek at how i load ui elements.

versed igloo
#

Thanks for the gist. Yeah, loading XAML should be easy. The hard part is that after loading a xaml, we need to traverse the tree and construct the corresponding UI objects on the client side. There should be many unsupported objects at the moment. I'll need to consider supporting xaml loading at some point though.

opaque flicker
#

you just find the commands to load the XML using winui3 and call it good. then you apply filters prior to the parse to create all of your UI element names.

versed igloo
#

Yeah, after loading XAML, UI objects are created by that function on the Server side which is fine. I will have to traverse the created object tree under Window.Content and then create the corresponding UI objects on the client (PowerShell) side. It should be doable but I need some time to implement it properly..

opaque flicker
#

and shim findnode and a few other commands to talk back to the ui

bright aurora
#

But I agree with Romero on the XAML loading -- do you really need to every control widget back to PowerShell? If people are building the XAML to design the UI, they probably just need a way to Register event handlers on the controls (by name), and get the "value" of things, right?

versed igloo
#

Right, not every node needs to be exposed to PowerShell.

Regarding the source generator in ShowUI, is it your original (generates .ps1)? or C# source generator?

bright aurora
#

That's a long story ... originally, we generated PowerShell script, but eventually we switched to generating C# and compiling it, for performance reasons (it was sooooooo much PowerShell).

#

And it was not this complicated at first 😄

versed igloo
#

Oh cool. Actually I see a lot of impressive work in ShowUI!

bright aurora
#

I keep thinking I should dig it back up, now that WPF is possible again

#

There's a few things that don't quite work, but it does (mostly) work

versed igloo
#

Now WinUIShell is targeting a WinUI version of pure WPF on PowerShell, but ShowUI is on another level, it has command suite and syntax.

bright aurora
#

Yeah, I started out trying to make a DSL

#

(and kind-of succeeded)

#

Based on adapting whytheluckystiff's Ruby Shoes to PowerShell and WPF (and I called it Power Boots)

#

ShowUi basically came from merging that project with "WPK" (which James Brundage of @summer perch wrote for the last ever Windows Server Power Tools)