Skip to main content

News

Topic: The Sphere Studio v1.2.1 (Read 200360 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
  • Last Edit: October 08, 2015, 03:13:18 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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 ;)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.7.0
Reply #514
No problem, I killed time by fixing bugs and polishing things up.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
  • Last Edit: October 18, 2015, 03:02:58 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
  • Last Edit: October 18, 2015, 11:18:03 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
  • Last Edit: October 18, 2015, 12:44:20 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #520

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

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
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?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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. :)
  • Last Edit: October 19, 2015, 03:42:47 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Radnen's Sphere Studio v1.1.7.0
Reply #523
I think the real answer is clearly that autohide should not be a part of that enumeration at all.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub