Skip to main content

News

Topic: The Sphere Studio v1.2.1 (Read 169560 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.2.1
Reply #570
Okay, I made the Quick Find control style-aware.  It's still a bit plain, but now it matches the current style at least, so it doesn't stick out like a sore thumb.

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.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.2.1
Reply #571
I forgot to post a screenshot before.  Here's what the Quick Find box looks like now.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.2.1
Reply #572

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.


Yeah, I agree here, but it's still very simple to just build the code out and "get it done". I've always found WPF a hassle to deal with, I mean html and css is easier than that. XAML? I mean come on!

Nice screenshot, BTW. I've been very busy and so I have not had the time to do anything lately. So, here's a screenshot of what I'm doing at the very least.
  • Last Edit: April 01, 2016, 11:53:04 am by Radnen
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.2.1
Reply #573
That palette feature does look really useful.  Especially for pixel art with a limited number of unique colors, I imagine it would be invaluable.  Oh, I don't know if you noticed in my screenshot, I finally found the Goldilocks point for the code font size.  I found the 10 point to be too small and the lines too close together, but 11-point was too large, especially on lower-resolution displays.  The solution: It turns out you can specify fractional point sizes.  What you see in that screenshot is 10.25-point Consolas.

Anyway, I need to stop screwing around with Sphere Studio so I can finish polishing off minisphere for the 3.0 release. ;)
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Radnen's Sphere Studio v1.2.1
Reply #574
Sphere-related tools getting improved is never "screwing around", if you ask me. Good work on this. :)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.2.1
Reply #575
@Radnen: I wrote a proper introduction in the README file:
https://github.com/Radnen/spherestudio
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.2.1
Reply #576

@Radnen: I wrote a proper introduction in the README file:
https://github.com/Radnen/spherestudio


Thanks, it needed a good update. :)
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.2.1
Reply #577
By the by, I ended up releasing minisphere 3.0 with a bundled copy of Sphere Studio after all.  I figured why not, the vanilla engine included an editor, so minisphere should include a modern one.  The bundled version incorporates my latest changes and UX improvements as 1.2.2, so if you want to do a minor maintenance release with that version number, that would probably be good to avoid confusion.  Just if you do, make sure to do a full clean and rebuild this time. :P  I've gotten into the habit of doing that for all my releases, so I know that everything's up to date before packaging.  Sometimes I'll even go as far as deleting the build directory completely to make sure all the stale files get nuked.

At one point I was considering forking the editor and bundling it as "minisphere Studio" (versioned in sync with the engine and toolchain, with all changes contributed back to the main repo of course), which the MIT license would allow, but I decided that probably wasn't a good idea.  Fragmentation is bad. ;)
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.2.1
Reply #578
Oh. I would have liked to add that dynamic palette I was working on, but lately I've just been so darn busy. Tonight I may work some more on it, and perhaps add it to the codebase. It's fully working but a bit difficult to use. I wanted to add an eye dropper and copy-paste/merge ability to the palette.
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.2.1
Reply #579
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. :P
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.2.1
Reply #580

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. :P


I understand the pain of the async/sync even at where I work. I guess if it's got to be done I can't see why not bumping up the version numbers considerably. v1.2.214 anybody? Anyways we don't have to release with each minor bug fix, so it's okay to go several releases and then release when we reach the middle or end of each month.
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.2.1
Reply #581
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.)  I tend to ignore that rule though because I don't want to end up releasing a hundred major versions in a year (minisphere would be up to v812.0 by now). :P  Usually if it's only a small change I'll "cheat" and just update the minor version (1.2 -> 1.3, for instance), or if I think the change won't affect anyone I've even been known to introduce breaking changes in a bugfix release.

I'm actually not sure how binary compatibility works in C#.  For example, can you change a method's parameters and only have it affect plugins that call that method, or will any breaking change prevent the assembly from being used entirely?  I feel like it's the former (which would make the most sense), but with .NET having strong naming and other such systems, it's not totally clear.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.2.1
Reply #582
AFAIK, if you use optional parameters, you're fine: http://stackoverflow.com/questions/12670735/is-replacing-an-optional-parameter-with-overloads-a-breaking-change

But I'm pretty sure a breaking change is a breaking change.


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


Hmm, I don't do that. If I break an API I bump the middle number. :P I bump the first number if it's been structurally overhauled in a major way. Otherwise small bug fixes ought to not be a problem.

BTW for Async/Sync issue, what we do at work and what is standard for .NET is to end the method call with 'Async' like "GetTransactionAsync()" and keep the older synchronous method call in place. Now, for a plugin system, I'm not sure what happens when you run two different versions of a DLL, in which the second DLL has only new stuff added to it. I think it will still work.
  • Last Edit: March 28, 2016, 10:56:44 pm by Radnen
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.2.1
Reply #583
Yeah, I'm the same way.  The official definition of semantic versioning is supposed to be, given X.Y.Z:


  • Bump X for any breaking change at all

  • Bump Y for any new features

  • Bump Z for bug fixes only.



But that's ridiculous because it makes refactoring anything very difficult.  A major version bump carries a lot of emotional weight not only for the developer but end-users as well, so you want to avoid doing it unnecessarily.  This makes it hard to make necessary changes.  So my take on versioning instead leans more towards:


  • X: Major overhaul or other important addition (e.g. minisphere got a proper debugger in v3.0)

  • Y: Breaking changes (anything that breaks the ABI)

  • Z: Bug fixes or minor feature additions (non-breaking)



It also allows for faster development when you're free to introduce features in a tertiary release. :)

Note that I said "ABI" instead of "API" above.  To me at least, source-level compatibility really doesn't matter since if you already have the ability to build from source, you can also make the necessary edits.  What matters here is binary compatibility: Can I swap out the underlying platform for a new version and still have everything work?  If so, it's non-breaking, even if source-level compatibility has been broken. (the term "binary" is a bit loose here of course--with some platforms like Sphere or Node.js, the API and ABI are one and the same).

So yeah, that's my two cents. :P
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.2.1
Reply #584
@Radnen: Alright, here's what I decided to do to avoid needing premature releases: For bundled copies of Sphere Studio, I'll use the version number of the most recent official Sphere Studio release and just add any fixes I need to make on top of that.  Only when you make an official release will I bump the version.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub