completed much of things I wanted to do before starting my port to Avalonia (of which I will certainly not force you to follow; this is a reason why forks exist). As such, it is a good time to merge my changes upstream. However, there are 134 commits in the queue and putting them in a giant pull request will make a review next to impossible.
There are several changes to the code organization you should be aware of:
- Every project in the solution is SDK-style, targets .NET Framework 4.6, 4.8 and Unified .NET 5.0 and 6.0 as well and all references are either PackageReference or ProjectReference (no more legacy Reference tags in project files)
- Until very recently, SDK-style projects prevented me to use PresentationFramework.Classic, which lead to graphic glitches and workarounds.
- I switched from package references for geometry4sharp and SolverFoundation to project references to my forked versions. It made managing multi-targeting easier and allowed me to make slimmed-down versions, specially made for SFView. Slimmed down versions saved 3 MiB on binaries, however their repos also need to be cloned alongside SFView. I don’t want to copy them into SFView (they don’t belong here) but I don’t know how to make an inter-repository link.
- I switched the JSON serialization library from System.Text.Json to fastJSON for all targets. It is a very small library (55 kiB, 10 times smaller than either System.Text.Json or good old Newtonsoft.Json/JSON.Net), handles polymorphic deserialization itself (you must give hints to System.Text.Json) and about 3 times faster than Newtonsoft.Json . However, its dictionary serialization is rather poor and I had to work around a bit. I am using the packaged version.
- Changing the source code view to AvalonEdit also meant copying 2 projects extending its capabilities. License-wise, there is no problem (there were MIT-licensed), it just makes the solution bigger. I put them in virtual folder in the Visual Studio solution. For AvalonEdit itself, I use its packaged version.
There could be code style conflicts too:
- I mainly use Visual Studio 2022 and JetBrains Rider sometimes
- For indentation, my preferences go to K&R placements of braces, adding them to 2-line statements and using tabs for indents, visually equivalent to 4 spaces. I never applied them to the entire codebase (this is rude behaviour), but to some files I was editing. This can make reviews harder.
Being able to modify SFView to add 2D graphics import/export capabilities greatly helped me on my UltraStarFox localization hack. Thanks.
completed much of things I wanted to do before starting my port to Avalonia (of which I will certainly not force you to follow; this is a reason why forks exist). As such, it is a good time to merge my changes upstream. However, there are 134 commits in the queue and putting them in a giant pull request will make a review next to impossible.
There are several changes to the code organization you should be aware of:
There could be code style conflicts too:
Being able to modify SFView to add 2D graphics import/export capabilities greatly helped me on my UltraStarFox localization hack. Thanks.