Skip to main content ↑ ↓
Topic: The Sphere Studio v1.2.1 (Read 2624556 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.
 

Re: Radnen's Sphere Studio v1.1.4.0

Reply #76 –
alpha123, I think there was an issue in 1.1.4.0 from the changes I made that required a certain property in the editor.ini (the dockforms property). You can use the editor.ini from 1.1.3.0 and it'll work as intended. In the next 1.1.5.0 this has been fixed thanks to Lord English. I actually think about dropping support for an alternate interface since the Weifen Luo dockpanelsuite has been made Mono-compatible. I'll just use it exclusively for now on.
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

Re: Radnen's Sphere Studio v1.1.5.0

Reply #77 –
Update
Alright, version 1.1.5.0 is up, it contains many small fixes, those of which LordEnglish made and some other notable changes:

- Document searching now uses full filepaths to tell items apart.
- The Alternate Interface has been removed it's 100% DockPanels now.
- Font Importing is now crisp, which is useful for pixel based games.
- Changes to the structure of Editor Forms (to make way for plugins in the future).
- Upgraded the DockPanelSuite to latest version.
- Separate builds for x86 and x64, yes, now there are 64-bit versions starting today. :)
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

Re: Radnen's Sphere Studio v1.1.5.0

Reply #78 –
@Radnen:

Am I supposed to be able to rename Tasks in the TaskList plugin? I'm getting an error each time I try to edit it. I can set the priority and the type of it, but I can't edit it.

In the dialogue it states: "BeginEdit did not succeed because LabelEdit property is false"

Here's the details of the error:

Quote

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidOperationException: BeginEdit did not succeed because the LabelEdit property is false.
   at System.Windows.Forms.ListViewItem.BeginEdit()
   at TaskPlugin.TaskList.EditTaskItem_Click(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3643 (GDR.050727-3600)
    CodeBase: file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
Sphere Editor
    Assembly Version: 1.1.5.0
    Win32 Version: 1.1.5.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/Sphere%20Editor.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3645 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3644 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3644 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Sphere.Plugins
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/Sphere.Plugins.DLL
----------------------------------------
WeifenLuo.WinFormsUI.Docking
    Assembly Version: 2.7.0.0
    Win32 Version: 2.7.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/WeifenLuo.WinFormsUI.Docking.DLL
----------------------------------------
TaskPlugin
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/Plugins/TaskPlugin.dll
----------------------------------------
ObjectListView
    Assembly Version: 2.5.1.20896
    Win32 Version: 2.5.1.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/ObjectListView.DLL
----------------------------------------
ScintillaNET
    Assembly Version: 2.5.2.0
    Win32 Version: 2.5.2.0
    CodeBase: file:///C:/Documents%20and%20Settings/Mike/My%20Documents/Sphere%20Editor/ScintillaNET.DLL
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3082 (QFE.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


(edit - wrapped error in quote box for easier reading ~neo)

Re: Radnen's Sphere Studio v1.1.5.0

Reply #80 –
Defiant, thank you for spotting that. You can't edit task lists with the drop-down menu anymore, I should have removed that option! You edit all properties by double-click. OLV got rid of the ability to directly open the sub-item editor, so I don't know how to do that via drop-down anymore. I will attach the new plugin here, but it really only removes that item.

N E O, I should do that. :)
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

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 here
Sphere Studio editor here

Re: Radnen's Sphere Studio v1.1.5.0

Reply #82 –
Is the image editor complete? I was going to sift through the topic but then I got a little lazy. Anyway, I can't seem to zoom in/out  on an image. Interesting to note is that zooming in/out works in the map editor. So I'm not too sure what the issue is.

Re: Radnen's Sphere Studio v1.1.5.0

Reply #83 –
The image editor doesn't zoom anymore. I got rid of that, but have the intention of bringing it back someday (I wanted to use a better method for zooming, the method I use on the map editor). Currently it auto-zooms with the size of the editing field - just like how the old editor does it. I made sure to at least fall back on the old editors behavior. The menu items well, are misleading I should gray them out.
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

Re: Radnen's Sphere Studio v1.1.5.0

Reply #84 –
Update
The Script Plugin is now live! I have been able to make it load up and edit files. My next task is to fully remove it's functionality from the editor. For example, there are many menu options that it still relies on. Menu options that the plugin must now implement.

So, I have two plugin interfaces now:
1. IPlugin
2. IEditorPlugin

The difference is, IEditorPlugin adds an additional contract: you must have made use of the EditorObject component. If you do not, then it is not an editor plugin. The task list is not an editor plugin, so does not use IEditorPlugin, but the Script Editor is an EditorObject and so must make use of it. Now, IEditorPlugin makes use of interface inheritance. That means, it must also have you implement all of IPlugin as well. The neat trick here, is that the IPluginHost can cast between IPlugin and IEditorPlugin whenever it can. That means IPlugin is all that needs to be relied on. The only limitation is that it's the hosts job to cast between the types so sadly it must know that beforehand which means you can't create your own plugin on the fly. But have no fear, I'll be developing various interfaces to facilitate the need to have subplugins and so on.
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

Re: Radnen's Sphere Studio v1.1.5.0

Reply #85 –
Quote from: Radnen – on

The neat trick here, is that the IPluginHost can cast between IPlugin and IEditorPlugin whenever it can. That means IPlugin is all that needs to be relied on. The only limitation is that it's the hosts job to cast between the types so sadly it must know that beforehand which means you can't create your own plugin on the fly. But have no fear, I'll be developing various interfaces to facilitate the need to have subplugins and so on.


Egh, this usage of casting is very hackish if I'm understanding it right, and having the host need to be pre-programmed to know which plugins are which types is very ugly, and actually destroys most of the advantages of having plugins in the first place.  There must be a cleaner way to do this...

Also Radnen, I sent you a pull request to fix the x86/x64 build options (all the projects weren't being built), want to check it out for me?

Re: Radnen's Sphere Studio v1.1.5.0

Reply #86 –
Quote from: Lord English – on

Egh, this usage of casting is very hackish if I'm understanding it right, and having the host need to be pre-programmed to know which plugins are which types is very ugly, and actually destroys most of the advantages of having plugins in the first place.  There must be a cleaner way to do this...


I could have just the one IPlugin interface, and it would have been pre-programmed to know things about it anyways. The only difference here is organizational. I don't know of a cleaner way. Basically, you must register to the project tree the filetypes and the plugin that loads those filetypes (Script Editor and .js files). When you double-click an item in the project tree (a script file ".js") it must open it as if it were an EditorObject (Script Editor implements EditorObject). If the plugin was an IEditorPlugin beforehand, then it knows absolutely that it implements an EditorObject and assumes it's safe to use. Not all IPlugins have EditorObjects, but all IEditorPlugins do. I think this is a great and safe method for figuring that out.

There is never full access to the host. A plugin must always speak through an API for the host to do things (like making a game in Sphere). The IEditorPlugin is just another way of talking to the host. I don't know if it's possible to create whatever plugin you want to make, it still comes down to a limited API. If I don't offer a way to change the title of the editor form, then there's no way of doing it, for example. Because of this, I see no disadvantage to the IEditorPlugin/IPlugin inheritance. At one point the host has to know things about the plugin. It's part of the entire plugin implementation.

Quote from: Lord English – on

Also Radnen, I sent you a pull request to fix the x86/x64 build options (all the projects weren't being built), want to check it out for me?


Hmm, you even got rid of the old task list stuff. I guess it's safe to move forward on this.
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

Re: Radnen's Sphere Studio v1.1.5.0

Reply #87 –
Update
I have finished the Script Plugin. I think it does everything that it did before. Just that it's now all contained as a plugin. I have not released the latest edition of the editor, but I think I should soon, but I want more plugins to be converted.

I'm wondering what people think of the plugin API so far:

- The host: https://github.com/Radnen/spherestudio/blob/master/Sphere.Plugins/IPluginHost.cs
- The plugin: https://github.com/Radnen/spherestudio/blob/master/Sphere.Plugins/IPlugin.cs
- The EditorPlugin: https://github.com/Radnen/spherestudio/blob/master/Sphere.Plugins/IEditorPlugin.cs
- The Task Plugin: https://github.com/Radnen/spherestudio/blob/master/TaskPlugin/TaskPlugin.cs
- The Script Plugin: https://github.com/Radnen/spherestudio/blob/master/ScriptPlugin/ScriptPlugin.cs

Is it too hard to understand? What do you think could make it easier? I just want general input. Because since I was able to fully implement the script editor into the Sphere Studio with this API, I think it's more or less right where it's going to be. I can't think of much more to add, but something might pop up.
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

Re: Radnen's Sphere Studio v1.1.5.0

Reply #88 –
I forget, does C# have implicit variable casting? I wonder if there could be a float/double Version property or if strings can be cast as float/double so that comparisons can be made for plugin updating from an online source and such. I know the open-source RetroArch (especially the GUI front-end) is really good about that.

Re: Radnen's Sphere Studio v1.1.5.0

Reply #89 –
By default, widening conversions (float to double, int to long, etc.) are implicit; any conversion that could lose information, however, must be cast explicitly.