I have no time this weekend. I upgraded my computer and it took a whole day out.

I like the fallback approach. It makes it seem more robust if you have no plugins activated.

As is usually the case for me, what started as a quick integration of Sphere Studio with Cell turned into a massive refactoring project:
https://github.com/Radnen/spherestudio/commits/cell-integration

The plugin system is in the process of a major overhaul.  Plugin modules are no longer limited to a single role, and can in fact serve many.  This is accomplished by having all plugins derive from IPluginMain and then, when they initialize themselves, they can register various roles for themselves, like this:

Code: (csharp) [Select]

cellCompiler = new CellCompiler(conf);
starter = new minisphereStarter(conf);
PluginManager.RegisterPlugin(this, cellCompiler, "Cell");
PluginManager.RegisterPlugin(this, starter, "minisphere");

The great part of this system is that RegisterPlugin() takes a reference to the PluginMain, so cleanup is simple:

Code: (csharp) [Select]

PluginManager.UnregisterPlugins(this);

The other new addition is Starters.  A Starter handles all the details of launching an engine (command line, environment, etc.) so that the IDE doesn't have to care what the details of the engine being used are.  As long as a compatible compiler is used, e.g. Cell for minisphere, everything works seamlessly.

Here's yet another new thing I'm working on, a Settings Center.  It collects all the configuration windows from various components (including plugins) into one.  In fact, settings pages go through the same plugin API mentioned above.

Yes, that's awesome. It's really needed. I was envisioning a menu like that for a long time. +1

This particular layout was inspired by the Winamp configuration.  A lot of apps (including Visual Studio) have a similar setup, but the idea of tabbed pages is something I've only ever seen in Winamp, and I really liked it, so I copied that design here.  It gives an additional level of organization that really matters sometimes--you don't get overwhelmed with a bunch of controls at once, but at the same time the sidebar doesn't get so full of sections that you can't quickly find anything (VS is guilty as charged here).

It's done: Everything which is user-configurable is now implemented through the plugin system: engines, compilers, editors.  This means that, with some tweaks to the project system, Sphere Studio could conceivably be used with any kind of game engine.

I left Sphere 1.5 support built in as a default fallback, but even it now goes through the new IStarter interface.

So, breakdown of what's new (note: not yet in master, needs further polishing first):
* Settings Center, collecting IDE and plugin settings in one place
* Builder/compiler support
* Pluggable engines
* "Swiss army knife" plugins - multiple functions in one plugin
* Less bugs!

One of my main goals with this refactoring was to knock down the dichotomy between "plugins" and "core editor stuff".  I think I accomplished that pretty well--plugins feel much more integrated into the experience now.  Plus it makes the codebase easier to maintain--features can easily be moved between different plugins or even into and out of the core at will.  It's awesome.

Here's a more revealing screenshot, showing as many of the new improvements as I could fit on one screen.

If you can clean some of your features up, I'll add them to v1.2.0 then update the description to include the new features.

Also, should we package the plugins with the editor or separately? What if we have a starter pack and advanced pack? Like the advanced pack has the debug tools - or are those going strictly with the minisphere bundle?

That's part of the reason for the Swiss-army plugins (the other being it was the easiest way to overhaul the system)--I was able to combine the minisphere-specific functions into one plugin.  That said, a standard and advanced package might not be a bad idea.  I don't think we have enough plugins to justify the split at present though...

As for inclusion, I think the basic Sphere format editors should be included with the main download, at least for right now.  We want this to be a complete Sphere 1.5 toolchain out of the box so it can be used as a drop-in replacement for the Vanilla editor.  It might be good to revisit this question later though, for v2.0.

I'm almost done with the overhaul, I just need to finish adding XML comments and then I'll give it a quick review to make sure there are no other implementation changes needed.  My main goal at this stage is to stabilize the plugin API so it doesn't need any further incompatible changes.  Making third-party plugins has been kind of a no-go till now because the public API keeps changing.  If I can get it to where that's no longer needed, that would be ideal.

The new API is going to take some adjusting to, but is a much more robust setup, and we can now add entirely new classes of plugins without breaking the interface for existing ones.

edit: I think it also might be a good idea to switch to semantic versioning:
http://semver.org/

Since we have a public API (for plugins), this makes the most sense.  I technically use SemVer for minisphere, but I'm not very strict about it--I won't usually break compatibility in a patch release, but I do regularly break things in minor versions.  It's actually very difficult to follow religiously (just fixing a bug may sometimes require a breaking change, for example), but useful as a guideline at least.

Yeah, I'm definitely going to convert over to semantic versioning. I've used it for basically everything else. It was just that when I started this I saw the MS versioning, but I never really used it right, partly because it's so bulky and obtrusive to use and almost require some automation for the minor numbers, which is not something I wanted to manage.

New version for this and all official plugins will be 1.2.0 when these changes are made. I'm holding off until then.

The last thing I have to do before merging to master is fix the embedded image and script editor shims, because they are needed for the map plugin but were broken by the plugin API changes.  That should be about another hour or so of work.

I'm quite happy with the results, Sphere Studio feels like a proper development environment now, fully customizable and everything.  The Settings Center is the best thing ever, I was about to add options for the minisphere debugger that had no place to go before this.

All the changes have been merged.  For cleanliness, I squashed everything down to one commit before pulling it into master.  Feel free to check it out.   Also take a look at the minisphere GDK plugin for a good demonstration of using the new plugin API.

To prove the engine independence, I moved the entirety of Sphere 1.x support into a plugin, Sphere Classic.  The IDE doesn't know or care what kind of engine you use now (for the most part, there are a few Sphere specifics still in the project system that can be worked out before v2.0), it's all handled by the plugin.  On that note, it should be much harder now to end up in a situation with no plugins are enabled, because the Configuration Manager will now warn you if no plugin is selected for an essential task before you close the dialog.  And in general the whole IDE is more resilient to missing plugins, which is nice.

As for removed stuff, there's just one thing: The SPK plugin.  Packaging is provided through the compiler plugin now, minisphere supports it via Cell, but I left it out of the Sphere 1.x plugin for now.  It would be easy to re-add it, but it's probably not worth the effort since Cell is compatible with vanilla.

If you make an official release, be sure to exclude the GDK plugin, it's incompatible with minisphere 1.x.

I never run out of ideas it seems... I started another project, updating the dock interface to make it possible for the editor to save visibility state of individual panels between sessions.  This new plugin setup I came up with is great for things like this, a lot of improvements that would have required a lot of effort before are now low-hanging fruit.

The IDEForm.cs is still a monstrosity though.  I'm gradually spinning stuff off of it to clean it up, but it's been slow-going.

Wait.. so you're saying it's no longer a "Sphere" Studio now?

I could then create modules for C# SFML and have an environment to create C# games... in C#!

Wait.. so you're saying it's no longer a "Sphere" Studio now?

I could then create modules for C# SFML and have an environment to create C# games... in C#!

Pretty much this, yeah.  As long as you're willing to write a compiler and engine plugin for it, at least.   The system is very extensible now.  The only real blocker is that the screen resolution and "startup script file" are still tracked at the project level (for Sphere 1.x anyway, Cell ignores the .ssproj and reads it from the cellscript).  If we could somehow get that dependency out of the core, it would be completely engine-independent.