Skip to main content ↑ ↓
Topic: The Sphere Studio v1.2.1 (Read 2624936 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #510 –
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. :D

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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #511 –
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 ;)

Re: Radnen's Sphere Studio v1.1.7.0

Reply #512 –
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! :P

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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #513 –
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Radnen's Sphere Studio v1.1.7.0

Reply #514 –
No problem, I killed time by fixing bugs and polishing things up.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #515 –
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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #516 –
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... :P

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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #517 –
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.

Re: Radnen's Sphere Studio v1.1.7.0

Reply #518 –
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 use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Radnen's Sphere Studio v1.1.7.0

Reply #519 –
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.
 

Re: Radnen's Sphere Studio v1.1.7.0

Reply #520 –
Quote from: Lord English – on

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 :)

Re: Radnen's Sphere Studio v1.1.7.0

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

Re: Radnen's Sphere Studio v1.1.7.0

Reply #522 –
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. :)

Re: Radnen's Sphere Studio v1.1.7.0

Reply #524 –
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. :)