Re: Radnen's Sphere Studio v1.1.5.0
Reply #81 –
Okay, I'm going to write this as more of a blog piece.
So, I was able to create a plugin of the script editor, but it doesn't work right now. Why? Because making it into a plugin is only a small part of the battle. This just means that I was able to strip away enough of the editor interface so that I can create a separate file and not have conflicts with types, and permissions. This is good, it's an indication of a good design. The next thing to do is make it interactive. And how should I go about that?
Well, the first thing to consider is what exactly I want to make into plugins. Eventually, I want to make all of the core editors as plugins. But most significantly there are three things I do not want to make into plugins, well several things but only three major ones.
1. The project tree.
2. The start page.
3. The menu bar.
The tree is going to be one of the few things 'built' into the editor along with the start page and menu bar. I need the start page because, heck, you could use the editor as a game launcher rather than just an editor, so it makes sense that this basic functionality comes stock. The tree should be there so it can list the file structure of each project when you open it. But it will not be able to open the individual art and script files (we'll get to that later). Lastly, the menu bar needs to be stock. There are a few menu options that will come with the editor. The rest shall be added by plugins as they are loaded.
With that out of the way, how is it that we can turn the script plugin into a full functioning piece of software? Well, the answer is in the utilization of the menu bar and the project tree. The host program would introduce methods to register a filetype to a plugin. The filetype is registered with the project tree view, so that when you double click a file, it looks up it's filetype and then launches the code necessary to add that file into an editor object and then that editor object into the main dock panel of the host. The menu bar is also registered to, but differently. The plugin registers to it a menu item that when clicked will begin the process of saving/loading/creating new documents of the editor.
The next problem is how free and open I make this API. If I give full access to the menu bar a user could accidentally destroy the menu bar when their plugin deactivates. But if I give too less freedom, then it might get hard to add custom commands to the menu bar. So, I think a plugin will allow you to manage your own menu item and add/remove that item from the menu bar. There's one caveat, adding your item to the menu bar will also add any necessary sub-menu's that are required to fully realize the menu item. What if you add a script sub-menu and in it a sub-menu for tab control? If I remove the tab-control item, it will not destroy the sub-menu for the tab control items. The fear here is what happens when another plugin extends the features of one plugin? This is possible, and so I think when registration occurs each menu item would need to be tagged with the plugin it comes from.
Currently, deactivation of a plugin can look like a mess. What if there was an easier way to deactivate? Activation would have to be a bit more involved since it requires the construction of items and placements, but once those features are added they should be easily removed. So, I'm thinking that each menu item and registered filetype contains a tag to the plugin that added it. Then when deactivated the host program does the heavy-lifting of searching for and destroying any references to that plugin.
And so, now I'm left with implementing this final, but crucial part.
Finally, I also intend to make the plugin list itself accessible by individual plugins. This way a plugin can search for a dependent plugin and then warn the user if the dependent plugin has not been installed. A map editor may require the use of a script editor. But why reinvent a script editor if it could just use one already provided by a plugin? Furthermore a plugin that extends another plugin may then be possible. A plugin just has to provide the API that another plugin must use to interact with it. So, in a way I can see a leap-frogging of plugins occur. But I must make it user friendly, with a sensible API. I don't want plugin creation to be too tedious or it would not be easy to have fun creating your own additions, etc.
I would therefore have to construct a tutorial as well. Possibly start a new github repo solely intended for the construction of editor plugins, utilizing the Sphere.Core and Sphere.Plugin API's.
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
hereSphere Studio editor
here