Community for the Sphere game engine

New? Contact Us to register an account!

I intend for people to make plugins separately from the editor. And so I may end up creating another repository for editor plugins. Perhaps get N E O to set one up among the official sphere repo's on github.

If I had to suggest one change to the plugin API, it would be to remove the explicit dependency on dockpanelsuite.  That's the one big thing that bugs me, since if in the future you decided to use a different, better GUI library (unlikely but it could happen), ALL existing plugins would break. That's the hardest part about designing a plugin API: You want it to be stable. Not like Firefox extensions where half of them break with every new release!

And not only that, but forcing the plugin author to create their own DockContent object means it'll be a lot more difficult to eventually implement saving the docking layout...

Other than that, no real issues with the plugin API, except maybe that you could redesign the IEditorPlugin interface to not inherit from IPlugin. Seems counter to the way interfaces are normally used. The contract shouldn't be "editor plugins implement IEditorPlugin", it should instead be "editor plugins implement IPlugin AND ISphereEditor".  Something to think about.

All right, I finalized the Sound Test plugin.  The only thing I couldn't do was register filetypes to it, since that apparently requires an IEditorPlugin implementation.  Oh well.  I just pushed one last commit into the pull request, your call now if you want to merge it.

Don't get mad at me, but I also renamed the events.  Events aren't supposed to start with 'On', that's the naming convention for the overridable protected method that raises the event (if one exists).

Quote from: Lord English – on May 01, 2013, 12:35:56 pm

Don't get mad at me, but I also renamed the events.  Events aren't supposed to start with 'On', that's the naming convention for the overridable protected method that raises the event (if one exists).

No, it's fine. I rename things all the time. I just had the habit of using 'On' for events, but they probably shouldn't use that. (Just, uh, tell me what you renamed so I can find things).

Edit: Hmm, seems I somehow missed your idea about custom events for file types.  That's a good idea, mind if I try my hand at implementing that?

Cross-thread operation not valid: Control 'SoundPicker' accessed from a thread other than the thread it was created on.

Cool, I merged the rquest. I'm getting a cross-thread issues when testing the editor with music playing:

Quote

Cross-thread operation not valid: Control 'SoundPicker' accessed from a thread other than the thread it was created on.

On line 134 of sound picker.

Woah, and this line of code is amazing:

Code: (csharp) [Select]

dirInfo.GetFiles(searchFilter, SearchOption.AllDirectories);

I did all of my recursive directory searches by hand, huh, never would have thought .NET would/could do this for you.

Edit:
I cleaned up your code file. Um, it suffered from some complexity issues that made the code hard to read. >.<
Don't fear, the changes are minor and stylizes it in such a way that it resembles (for the most part) other portions of the editor. I don't like using 'this' everywhere and I usually put an '_' underscore prior to a private field. I also use a lowercase letter such as 'm', but I did not choose to use that style for this project. I hope you don't mind.

I guess that's okay.  It's just that I don't like not qualifying references to instance variables, since that can cause problems if you're not careful--for example, if you have a local variable with the same name as a private field, when you assign to it which one are you referring to?  The compiler could probably figure it out, but someone reading the code may not be able to at a glance (I'm a big advocate for self-documenting code). And naming instance variables with conventions like 'm_' etc. I feel is hackish when the language already has a method built-in (this) to resolve the ambiguity. You're already referring to instance fields as obj.something from outside code, why should it be any different on the inside?  But yeah, it's an official plugin now, might as well keep things consistent.

For what it's worth though, I find the "cleaned-up" code harder to read than the original version. I see the underscores, yet I have to keep reminding myself "Underscore, okay, this is an instance field, not a variable"--it's not as instinctive as when I see 'this.fieldName', if I see that then I immediately know where to look for a declaration.