Why was the Avalonia fork a fork, instead of a full switch on the main project?

[slxdy]

I was wondering, since the Avalonia fork got archived for lack of maintainers, why was there never a plan to upgrade the main project to Avalonia?

[christophwille]

AvaloniaILSpy was archived for lack of maintainers. As an aside, keeping two codebases in sync is hard, even though we tried to reduce the surface area with the introduction of ILSpyX (in hope of making life easier for prospective maintainers).

There was a PoC from the Avalonia team for their XPF product, and in the process of working with them we reduced old Windows (API) dependencies. However, as XPF is not open source, it wouldn't have landed in our main repo anyways.

Now, as for "ILSpy moving from WPF to Avalonia": this is a possible future, but not one we are actively working towards. What would be welcome is deep research where we'd hit roadblocks in terms of current UI controls / third-party libraries that we are using.

[slxdy]

For the last part, I'd argue Avalonia is way ahead of WPF. Sure, the default style definitely looks different, but it's nothing that can't be changed.
As for third party libraries, which libraries are we talking about?

[christophwille]

We don't know what works and what doesn't. The AvaloniaILSpy fork was unmaintained for years, and we moved ahead meanwhile.

WPF is mature and won't go away - we don't care if it improves by leaps and bounds, our UI has been rather stable (exceptions being the refactorings). Moving to something else must have two properties: low risk and user base. Back in the day, it wasn't a given that Avalonia would be around x years in the future. And still the user base is small (Linux, Mac). One upshot though would be that development of the entire application could happen on any platform which isn't the case today.

Our current "stopgap" approach for other platforms is to provide the mainstream functionality of ILSpy via the VS Code extension.

[slxdy]

I'll see if i can do something in my free time

[christophwille]

All research is welcome.

Existing information you can build on is the thread icsharpcode/AvaloniaILSpy#136 (ignore the XPF bits) - it contains information on stumbling blocks as well as @maxkatz6 branch from last year.

Edit: also note that Avalonia 12 is coming soon.

[christophwille]

Just so there are no misunderstandings - we will definitely ship ILSpy 10 as a WPF version (too far along already). But forward-looking we can imagine being xplat (if it is easy enough for us, that is all WPF features are readily available in Avalonia).

[christophwille]

I missed to answer the subject of the question "Why was the Avalonia fork a fork, instead of a full switch on the main project?" - because it started independently as a fork, and only later we asked the developer to join the ic#code org.

[slxdy]

Can you point out where? I checked the source and couldn't find anything

[tom-englert]

What are you looking for? ObservableObject?

[maxkatz6]

With pre-existing applications, I often see no point in changing MVVM framework.
There could be a case with old MVVM frameworks that been reflection based or being otherwise outdated by modern .NET guidelines, but I don't think ILSpy is using one like that.

Another case might be specific to OSS projects - contributors familiarity, using tech that most of contributors are familiar with. In this case using the popular option might justify migration but really depends on the team capacity.

[christophwille]

If file size is an issue, I can assure you CommunityToolkit.MVVM is VERY light. It's mostly just source generators https://github.com/CommunityToolkit/dotnet/tree/main/src/CommunityToolkit.Mvvm

It is not about size, it is about doing the same thing multiple ways.

[tom-englert]

Also looking at https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/ioc#what-about-viewmodels:
They are propagating the view first approach, which is kind of "WPF for WinForms users".
I'm preferring the model first approach, which is the basic idea behind WFP:
Content of a ContentControl is the ViewModel, not the View.
The view is then just a DataTemplate for the ViewModel and will be picked up by the ContentControl automatically.
View first is like setting the content of a ListBox with manually generated ListBoxItems - you would never do that.