Contribute to the Maui backend for GTK and/or Qt, nothing is stopping you
Alternatively, just because you're on .NET doesn't mean you need to use Microsoft sanctioned UI toolkits, just as C++ has no "official" UI toolkit. You're free to pick up some GTK or Qt bindings if you want a native feeling and your application is already architectures correctly. Alternatively, throw Imgui at it if you just need dev tooling, or maybe try other cross platform toolkits in the ecosystem like Avalonia or Uno
With commercial applications that want to just take their existing code and have it run on Linux with only a couple lines changed, Avalonia XPF will do that
Yup, this was it for me, GitHub was actually pleasant to use, to browse, PRs were easy, branching was easy, PRs with reviews/comments/etc were a brand new concept, especially as SourceForge and Google Code were hosted only on SVN which constantly fucked up/corrupted data in my experience
The closest thing to PRs that I knew was reviewboard, and that was a bolt on to SVN, not an actual proper integration
I don't necessarily agree. Using shared_ptr to not worry about lifetimes, a la C#, is not inherently a bad thing, not all code has to pretend to be Rust, especially a hobby project. From what I see, they're only really being used as dependency injection. So it has the benefits of the garbage collected model with none of the downsides
Also, speaking as a C++ game developer by profession, taking a shared_ptr copy and moving from it is a common way of saying "I will take a copy of this and keep it alive" whereas a shared_ptr ref only communicates that it can or might
RAII using a unique_ptr in this case would have the benefits of a GC without any of the performance loss of an atomic or a lock depending on implementation.
Regarding "I will take a copy and ... keep it alive..." That is literally what the copy constructor of a sharedpointer does, you wouldn't need a move for that, the move literally just prevents the atomic increment.
I'm not saying there isn't a use case for shared_ptr, just that in this codebase at least in parts of it you could string replace with unique_ptr and get a free performance boost ( as trivial as it would be if the compiler hasn't already just done that ) because the atomic ref count is not needed.
OP did however clarify some design decisions on why the shared_ptr in some parts of the code and that is fine.
I stick by my statement. Stop using std::shared_ptr. Use std::unique_ptr and then convert to shared when it is actually necessary.
My point in C# was a mean spirited dig, but really though, you are giving up a ton of library features from C# by coding in C++ to then just treat it like C#. Write it in C# using the library that has already been optimised...
Alternatively, just because you're on .NET doesn't mean you need to use Microsoft sanctioned UI toolkits, just as C++ has no "official" UI toolkit. You're free to pick up some GTK or Qt bindings if you want a native feeling and your application is already architectures correctly. Alternatively, throw Imgui at it if you just need dev tooling, or maybe try other cross platform toolkits in the ecosystem like Avalonia or Uno