Skip to main content

News

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

0 Members and 6 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.5.0
Reply #105
So thanks to your plugin tutorial (I'm a hands-on type of person so I didn't even check the wiki page, just opened up the MyPlugin project and went from there, thanks for making that! :) ) I managed to implement an audio player, but I went in a decidedly different direction to the existing player: "Sound Test", styled after the Sound Test modes from the old Kirby games.  Basically it adds a tab to the sidebar which lists all the music tracks and sounds in your project and lets you double-click one to play it without leaving your current map/script/whatever.  Much better, I think, than opening a separate document window for audio. This interrupts your work, however briefly; losing your train of thought is never fun!

I opened a pull request to merge it in, that's been open for a few days now I think and thanks to my perfectionism has accumulated a total of 7 commits...  and I think there might have been a hotfix for the editor in there as well, don't remember.
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.5.0
Reply #106
I have not really edited the editor since my last commit, so your changes would be easy to merge. Of course, if I want to even merge it. 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.

I'm very happy that you made a plugin! Now there will be varying authors among the plugins. Tell me, what part of the process needs improving? What more access do you want (to the Host)? Did you find out how to read/write to the editor settings? Because I supply an editor settings object for you to read from / edit. You were using a more or less incomplete plugin API to do this, so granted that later on there should be more stuff: such as sub-plugins.

Edit: What changes to the editor did you do? Or were they all plugin related. Furthermore, one thing that can help you (that I haven't yet added) is an 'about to play game' event that you can hook onto. That way you can pause all playing music/sounds when you play-test the game.
  • Last Edit: May 01, 2013, 04:56:08 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.1.5.0
Reply #107
I had a feeling you'd have reservations, but I intended for the Sound Test to be a full replacement for the existing audio player, a component I consider an integral part of a default game-making IDE along with the script and map editor, that's the only reason I proposed a merge.  There's a few other changes I'd have to make to it to meet that goal (registering the proper file types for one!), but that was the intent.

As for the editor fix, it turns out it was just a quick hotfix to move the Open Last Project code AFTER plugin evaluation so that plugins get an OpenProject event for it.
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.5.0
Reply #108
I guess if you round it out, I'll add it as an official plugin. But after that, I really want to develop a toolkit that people and go download and use. It'll contain the test "MyPlugin" code, and the dependencies that it needs: dockpanelsuite, Sphere.Core, and Sphere.Plugins. From there the user can then build their own custom plugin away from the editor. Because having the editor code is a bit like cheating, since in the end, you can only talk to it via the Host API.

In your case you can spot bugs and fix them, :P
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.5.0
Reply #109
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. :)
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.5.0
Reply #110
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Radnen's Sphere Studio v1.1.5.0
Reply #111
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.


Done! Right now Radnen and Bruce/Lord English have push+pull access to the repo; anyone else let me know if/when you want to have push access, otherwise follow the usual GitHub pull request procedure.

@Radnen - eventually, once Sphere Studio finally supplants the original editor I'd like to see it become the official editor for now and would recommend eventually transitioning the repo over to sphere-group under the repo name sphere-studio (the hyphen for consistency with the other repos). You could move it, refork it back to you, do all your updating on your version, then merge with the sphere-group version once tested. How does that sound?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.5.0
Reply #112
@Radnen -
Just added another commit.  I implemented the TestGame event you suggested above (good idea!), so now Sound Test automatically pauses any playing music when you click the Test Game button.

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).
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.5.0
Reply #113

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!


Yeah, thinking about it, you are right. But the only other issue is then creating an abstraction layer between the plugin API and editor. I need some way for the user to do their styling away from the dockpanel API that is also consistent with it and not to specific to it either. Hmm...


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


This is going to be a harder problem to solve anyways. Suppose you have plugins activated all over, then delete your editor.ini file but not the spheredock.xml file. It'll attempt to dock objects that it cannot access. I guess it could just silently fail for those. But then trying to reposition them if they do exist may take some other data. I'll have to look into that.


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


Oh I've thought about that, and inheritance among interfaces is a good way to go for something like this. But you are also right, there's been whole debates! But apparently MS had an idea good or not to include interface inheritance. The idea of multiple interface inheritance is not really all that cool.


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.


The file registration is only for double-clicking filenames in the project tree. I'm thinking of perhaps a better way to register filetypes. So that custom events happen when clicking on certain filetypes. Which means, I might actually be able to get rid of IEditorPlugin altogether. (You do the work of determining if you attach an editor object or not to the Sphere Studio) which is what I ideally wanted anyways.


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).
  • Last Edit: May 02, 2013, 02:16: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.1.5.0
Reply #114


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


All right, OnOpenProject is now called LoadProject, OnCloseProject is now UnloadProject.  And the new one I added at your suggestion is TestGame.  Since these are part of the public plugin API, I figured it was best to stick to the same naming conventions as WinForms uses, to minimize confusion.

As for multiple inheritance of interfaces, I don't really have an issue with it.  An interface is not a class, but a contract.  Multiple class inheritance doesn't make much sense (one of the dumber features of C++ if you ask me, and complex as hell--I'd hate to have to write a C++ compiler!), but there's nothing wrong with "signing" two different contracts. :)  I suppose you could make the case that IEditorPlugin is a subcontract of IPlugin (i.e. to extend the metaphor, you can't sign the latter contract without first signing the former), but I don't know, the setup still bugs me, I can't put my finger on why...

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? :)
  • Last Edit: May 02, 2013, 06:36:56 pm 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.5.0
Reply #115

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


Sure, I'm super busy, as you can tell, I haven't really touched the repo for a while.

Anyways the idea is to create an event that is triggered when someone double-clicks an entry in the project tree. I think you should develop a custom EventArgs that stores the filename that was clicked. Then it's up to the plugin's callback that will be passed to the event to determine if it should or should not open a file of that type. This basically offloads type checking onto the plugin creator than the editor, but it gives more freedom.

This also completely removes filetype registration. But this method can be slower. Since if 8 plugins add 'listeners' to the event handle, then 8 functions are triggered, each checking if they can open that filetype. If there is a match, well, it would be weird but it is possible that two plugins can attempt to open the same filetype. The original idea of the registry was to avoid this.

There is a more complex path that is a hybrid of the registry and the event versions. You sign on to the registry what types a plugin can open, then when the user double clicks, send out only the event for that particular filetype. In this way, there's a 1:1 relationship with plugins and filetypes, and only a single event is triggered when the user double-clicks a file, rather than 'n' amount.
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.5.0
Reply #116
All right, done.  Works wonderfully, Sound Test even plays stuff right from the tree now.  I think I may have had a bit too much fun with this though... check the commit descriptions and diffs if you don't believe me.  :D
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.5.0
Reply #117
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.
  • Last Edit: May 03, 2013, 04:42:48 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.1.5.0
Reply #118

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.


Odd, I never had any issues like that and I was constantly playing music and changing tracks throughout my testing just to stress test the thing.  I didn't think the editor was multithreaded though, that's a really weird error. ???

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


That's why I love the .NET Framework. 9 times out of 10 the framework will do the manual labor for you, you just have to go deep enough. (Inception reference... okay that was terrible, don't shoot me please :-X).  If you've ever heard the framework described as "the mother of all dependencies", this kind of thing is the reason why. ;D

Quote
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.
  • Last Edit: May 03, 2013, 09:25:57 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.5.0
Reply #119

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.


I understand, but I still think it's largely a stylistic issue. You have made an official plugin for the Sphere Editor, and so it should be styled like everything else. If you made it so it would be apart from the editor, I wouldn't mind. Your issues with the convention are, well, due to the fact you are not really used to my code style. When I go online I see many ways of code styling's and each one is a bit different, so this is a problem that I have too. Not everybody uses 'this', and not everybody uses a private field convention, and if they do it's very different from other peoples code.

Personally I don't use 'this' because it's more to type, it adds a lot of blue around the screen, makes long lines longer, and I know what the instance fields were. Very rarely does an instance field equal a local variable, usually in the constructor function this happens or setter functions. I use an '_' underscore because I have grown to read that as a private instance field, same with other conventions such as 'm_', etc. So, as I said it's really just a style preference.

It would be cool someday to work on an open source project with multiple authors and the IDE styles the code to everyone's preference when the file is open, then styles it to a project default when it closes. :P
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