For the record, LINQ was an invaluable tool for this overhaul.  I've gotten very good at employing it now, having used your Link extensively throughout Specs.  Despite the various disparate types of plugins, all registered plugins are stored in a single flat List<> and the correct ones are picked out using LINQ and reflection.  It's really quite elegant.

One thing I'm debating is whether I should move the Configuration Manager (preset editor) into Settings Center.  Thoughts?

edit: I added a few tips to check plugin settings when an error occurs due to a missing handler.  One thing I noticed came up consistently in testing is users were confused when starting from a fresh install, double-clicking files caused a "can't open this kind of file" error since there are no plugins loaded.  So now the editor points them in the right direction.

The new plugin system is so powerful that I was able to convert a lot of _internal_ components, like the Start Page and project tree, to use the plugin interface.  Doing so served to clean up the code even more, and also fixed a lot of glitchiness caused by the core components interacting badly with plugins.  Since these components are actually plugins themselves now, just registered internally, they get along much more smoothly this way.

And here's another screenshot, just to show everything is still functional and I didn't break anything

Okay, I moved the minisphere plugin out of the SphereStudio repo and into minisphere proper.  That's part of the reason I wanted to get the plugin API finalized, so it would be less painful to develop the plugin separate from the IDE.  The other reason is... well, it was just no fun to make plugins before!

I also added source for an Inno Setup installer to the repository.

I was going to look at this this past weeked, but I got caught up in other things (a personal project I'm working on for a paying client). Next weekend I'll take another look. I'm hoping to have a quieter weekend then.

No problem, I killed time by fixing bugs and polishing things up.

New feature: Toolchain (engine and compiler) can now be set per-project.  So if you have some games using minisphere and some using Sphere 1.x, the IDE will automatically switch to the correct toolchain when opening the project.

SGM import is broken now, though.  I'm considering how to go about fixing it.  Watch the GitHub issue for status:
https://github.com/Radnen/spherestudio/issues/54

Okay, SGM import works again, through a new File menu item "Upgrade SGM".  The editor will no longer open SGMs directly anymore because with the new build system and dist/ directory, the extra .sgm files end up cluttering the start page and could even cause you to lose progress if you accidentally edit a compiled dist instead of the original project...

I also added saving dock pane visibility.  Now if you close a panel, it will still be closed after you restart the editor.  AutoHide state is remembered, also.

Finally, I changed the way engines are handled.  Now you can switch between all installed engines and test games with any of them at will.  It's basically an evolution of what you could already do with presets in 1.1.7.0, but wired directly into the plugin manager so you no longer need to manually make a preset for each engine.  As long as the plugin for an engine is installed, you can select it from the toolbar.

Let me also just reiterate for the record just how horrid the Weifen Luo API is.   At least it's more maintainable now, all the dock handling is confined to a single module (DockManager.cs) rather than all over the place like it was before.  And plugins don't have to care about its idiosyncrasies at all--just implement IDockPane (a mere 4 properties!), pass it into PluginManager.Register() and call it a day.

On a minor sidenote re: the Weifen Luo controls, I think this is the most awesome piece of code I've ever written:

Code: (csharp) [Select]

bool autoHide = Core.Settings.AutoHidePanes.Contains(name);
DockState state = plugin.DockHint == DockHint.Float ? DockState.Float
    : plugin.DockHint == DockHint.Left ? (autoHide ? DockState.DockLeftAutoHide : DockState.DockLeft)
    : plugin.DockHint == DockHint.Right ? (autoHide ? DockState.DockRightAutoHide : DockState.DockRight)
    : plugin.DockHint == DockHint.Top ? (autoHide ? DockState.DockTopAutoHide : DockState.DockTop)
    : plugin.DockHint == DockHint.Bottom ? (autoHide ? DockState.DockBottomAutoHide : DockState.DockBottom)
    : DockState.Float;  // stacked and nested ternary = awesome

Funny thing is, I used to avoid ternary conditionals like the plague, thinking they made the code harder to read.  But had the above been written as a traditional if/else tower... *shudder* (I still would have found a way to make it as compact as possible though ) Nowadays I use them all over the place.

It looks to me that the code maps between the generic dock parameters and Weifen Luo dock parameters. I generally dislike humongous ternary operations because if nested too much they get nearly impossible to follow. But for this one you managed to lay it it out very neatly.

Another solution would be to use some kind of bit mask or some array map() function.

If you peruse the minisphere codebase you'll see I use a lot of stacked ternaries.  I don't generally nest them like I did here though.  The biggest challenge in this case is that 1) the DockState enum is sequential (see comment above on terrible API design) and 2) there is no separate AutoHide property for DockContents.  So the only way to cleanly map between them was some sort of conditional construct.  This seemed like the cleanest method.

edit: Related, let me just say whoever came up with short-circuiting for logical and/or is a freaking genius.  Being able to encode a null check and property access in one operation is pretty much the best thing ever.

Code: (csharp) [Select]

bool autoHide = Core.Settings.AutoHidePanes.Contains(name);
DockState state = plugin.DockHint == DockHint.Float ? DockState.Float
    : plugin.DockHint == DockHint.Left ? (autoHide ? DockState.DockLeftAutoHide : DockState.DockLeft)
    : plugin.DockHint == DockHint.Right ? (autoHide ? DockState.DockRightAutoHide : DockState.DockRight)
    : plugin.DockHint == DockHint.Top ? (autoHide ? DockState.DockTopAutoHide : DockState.DockTop)
    : plugin.DockHint == DockHint.Bottom ? (autoHide ? DockState.DockBottomAutoHide : DockState.DockBottom)
    : DockState.Float;  // stacked and nested ternary = awesome

Sometimes, integral enumerations are very convenient

Wait, why couldn't you use a switch block on that instead? You said the constants enumerate to ints, right?

The switch block would be more verbose.  This is nice and concise at 5 lines, a switch would be about double that.

By way of example, compare the above to:

Code: [Select]

switch(dockHint) {
case DockHint.Left:
if (autoHide) state = DockState.DockLeftAutoHide;
else state = DockState.DockLeft;
break;
// repeat for each case
}

I'm a firm believer in DRY.

I think the real answer is clearly that autohide should not be a part of that enumeration at all.

I agree, but I didn't design the API.  Which is what makes that stacked ternary so impressive (to me, anyway)--it maps a terrible enumeration setup to a much more sane one.  I'm resourceful and good at working with what I'm given.