Skip to content

Planning for merging Repzilon’s fork #7

@repzilon

Description

@repzilon

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:

  1. 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)
  2. Until very recently, SDK-style projects prevented me to use PresentationFramework.Classic, which lead to graphic glitches and workarounds.
  3. 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.
  4. 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.
  5. 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:

  1. I mainly use Visual Studio 2022 and JetBrains Rider sometimes
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions