It seems there's only so much you can really do with WinForms. As much as I hate the complexity of WPF and similar frameworks, I can understand the appeal. You can make very rich interfaces with it (see: MSVC 2010 and later) whereas WinForms is quite utilitarian and rooted in rectangular controls.
@Radnen: I wrote a proper introduction in the README file:https://github.com/Radnen/spherestudio
One thing that's a pain now that Sphere Studio uses semantic versioning is that I have to be very careful when making changes not to break the plugin API. Being a huge perfectionist, I'm often tempted to do mini-refactorings on the plugin system but have to stop myself because it would break plugins. For bundled plugins this isn't a problem (they can just be recompiled along with the editor), but it is for third-party ones like the minisphere debugger because it would break both backward AND forwards compatibility.To clarify a bit, in .NET it's safe to add new methods and classes without breaking anything, but changing method signatures (= return type, adding/removing/reordering parameters) or names will break plugins. This is the main thing holding me back from redoing the styling API (it badly needs an update), because I haven't yet figured out how to do it and still keep plugin compatibility.Incidentally this is one thing I don't like about the way async/await is set up: you can't change a method between async and sync without it being a breaking change. I understand why that's the case for technical reasons, but that doesn't make it any less frustrating.
Strictly speaking, by semantic versioning rules, if you break any APIs at all, you're supposed to bump the major version (1.x -> 2.x -> 3.x, etc.)