Support WindowsCommunityToolkit

[VincentH-Net]

There is a C#-only part of WinUI3 - WindowsCommunityToolkit, that as I understand, not supporting.

Originally posted by @YegorStepanov in https://github.com/VincentH-Net/CSharpForMarkup/issues/19#issuecomment-1000878827

[yoshiask]

I would just like to point out that the Windows Community Toolkit is completely unrelated to WinUI 3. It's a library for WinUI 3 and UWP apps containing useful helpers and controls.

[nerocui]

One way to do this is to make CSharpMarkup an official part of the community toolkit and use some kind of code gen to achieve supporting both XAML and CSharp markup for the controls.

[listepo]

I agree with @nerocui this project deserves it

[listepo]

@VincentH-Net @michael-hawker what do you think?

[VincentH-Net]

@listepo it's possible; the scope of this issue is to create a NuGet with the C# Markup 2 APIs for the WinUI 3 controls that are contained in the WindowsCommunityToolkit, e.g. CSharpMarkup.WinUI.WindowsCommunityToolkit.

A possible evolution of that would be to include those APIs in the community toolkit itself.

The existing C# Markup 2 APIs for WinUI3 itself in the CSharpMarkup.WinUI NuGet could also become a part of the WindowsCommunityToolkit.

The codegen to generate the bulk of the API's already exists - it would have to be finetuned to support more than the core WinUI 3 controls but that is certainly possible. That codegen is not OSS btw; depending on interest, I may make that available as a service and/or sell / license it to UI framework / control library companies.

Including C# Markup 2 API's in the community toolkit would promote adoption, although it would slow down evolution. Fast initial evolution is why I start out with C# Markup repo and NuGets. This could be the right time to make the switch to broader adoption though.

Btw C# Markup 2 as a whole has a wider scope than WinUI 3 - it potentially applies to all .NET UI frameworks and control libraries, even Blazor or a potential C# wrapper for Flutter.

[michael-hawker]

I agree that it probably makes sense to keep things separate. Our processes are complex enough at the moment to build the toolkit, so wouldn't want to add in another layer of generators on top of that right now.

[VincentH-Net]

so wouldn't want to add in another layer of generators on top of that right now

@michael-hawker when would be a good time to revisit this? (usually complex systems do not become simpler over time 😉 )

[michael-hawker]

I'm not sure, having a separate package for this additional functionality makes the most sense to me, therefore it being a stand-alone part of this repo or another repo makes sense from that perspective.

We've done a lot of work over the last couple of years to try and scope-down our dependencies and break-apart pieces from one another. This would add more to each package to support alternate syntax not everyone may use and add bulk if they don't do extra work to fully enable trimming in their application, right?

From that standpoint, it's a hard sell for us, especially with the additional maintenance overhead unless everything was just auto-generated automatically, but then at that point it could just ship as a side-package to augment what's already there being automatically spun out of the codebase from another process.

[abdes]

Honestly, not supporting the Windows Community Toolkit controls is an inhibiting factor for the adoption of C# Markup. Almost all of the controls in the CTK are required and without them WinUI is so limited. Take for example the Grid Split, Settings Card, Settings Expander, ...

If you can generate code, why forcing the user of C# Markup to hand-code the same controls than the CTK?

[VincentH-Net]

@abdes the groundwork has now been done to make it much less work to add support for additional libraries; I will look into adding the Windows Community Toolkit again. Btw my intention is to make the codegen available as-a-service; that is the next step