Porting WinForms controls to Modern.Forms

[majorsilence]

I'm exploring porting the Majorsilence Reporting desktop UI (https://github.com/majorsilence/Reporting) from WinForms to a cross-platform toolkit; it currently targets net8.0/net10.0.

I noticed recent PRs that ported or fixed WinForms-style behavior with Copilot assistance:

• PR Port DataGridView control from WinForms to Modern.Forms #121
• PR Remove ConfigureAwait(false) from system dialog classes #118
• PR Fix Label Multiline by adding Multiline to IHaveTextAndImageAlign and updating layout/rendering #105

1. Do you accept contributions created with Copilot or similar tools, and are there attribution expectations?
2. Are there license/CLA requirements or restrictions when porting WinForms code into Modern.Forms?
3. What acceptance criteria do you expect for control ports (behavior/API parity, visual parity, tests, performance)?

[jpobst]

Do you accept contributions created with Copilot or similar tools, and are there attribution expectations?

Yeah, I think it's fine to use these tools (as I've done). I think the key is that a human still reviews and tests the work. Having an AI generate lots of code and dumping it on me forcing me to test and fix it probably won't go over well. I don't really have an opinion on attribution.

Are there license/CLA requirements or restrictions when porting WinForms code into Modern.Forms?

Winforms is MIT licensed like Modern.Forms so it's fine to port code over. Generally you can't remove their license headers from their files, like https://github.com/modern-forms/Modern.Forms/blob/main/src/Modern.Forms/FormCollection.cs.

What acceptance criteria do you expect for control ports (behavior/API parity, visual parity, tests, performance)?

Honestly it's pretty arbitrary. The goal of Modern.Forms is to "conceptually compatible" with Winforms but also to be a modern evolution of it, which necessitates changes. In general I try to implement what I imagine is the most commonly used features of each control and leave the less popular ones until someone asks for them or contributes them.

Visual parity isn't really a necessity since most Modern.Forms controls have a more modern look that Winforms.

Performance is important enough that the base cases work, but stress test cases aren't really considered. For example, if you put thousands of items in a ComboBox I suspect the performance will be bad or even unusable.

There's very few tests since we don't have a testing setup that handles visual results, which is the majority of what we would need to test. I try to put common scenarios in ControlGallery which is what I use to do most manual testing.

[majorsilence]

Thanks for the info.

The goal of Modern.Forms is to "conceptually compatible" with Winforms but also to be a modern evolution of it

I'm going in a different direction, so it's probably best if I keep my fork a hard fork — renamed, with license/attribution notices pointing back here. My fork is focused on being as identical to WinForms as possible, using Avalonia or Uno as the base layer via NuGet packages.

The intent is to give teams a jumpstart (or a crutch) for quickly moving legacy WinForms apps onto a modern Avalonia or Uno platform, so close API/behavior parity matters more to me than a modern look.

Having an AI generate lots of code and dumping it on me forcing me to test and fix it probably won't go over well. I don't really have an opinion on attribution.

There's a lot of AI-generated code in my fork. I won't dump it on you, but you're welcome to pick through it for anything useful. I'll also keep the original license headers intact on any ported files.

Thanks for the work you put into Modern.Forms — it's been a blessing and a great starting point.