Why didn't we use Mono for the editor?

Started by ForeverZer0, May 15, 2012, 10:26:02 pm

Previous topic - Next topic

ForeverZer0

I was wondering.

It would have made the editor a cinch, allowed us to use several different languages, and maintained cross-platform compatibility.
The framework is stable and holding compatibility with .NET 2.0.

This is mainly just me bitching about Python and not being able to use my preferred language, but in all reality, the only downside I see is adding Mono as a dependency. I didn't know if this decision came from a misconception of the stability or ability of Mono, but I have personally experimented with it with great results. I even have Mono Tools installed in VS, so I can quickly test in a Mono environment with the click of a button, which I then have ported to Ubuntu and Snow Leopard VMs and used just the same. 

I realize this is extremely late in the game to try and seriously push the issue, but I think the editor would have been done long ago if we could have used the power of VS to build it.  PyTools is a massive help, but it can't even compare.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Ryex

I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

May 16, 2012, 12:14:00 am #2 Last Edit: May 16, 2012, 12:15:04 am by ForeverZer0
Seriously? I'm pretty sure I suggested this at the onset of the project, though I didn't go into any details...
 
Its a cross-platform implementation of .NET. You can use it to make .NET WinForms and deploy them on Linux, Mac, Android, etc. platforms and vice-versa. There are different GUI toolkits, but the normal "System.Windows.Forms" is implemented, so you can use VS's designer to create the actual form, and deploy it using Mono instead of .NET. There is also a GTK+ toolkit, but the only IDE I know of with it is MonoDevelop, which is not near as nice as VS. Its how Paint.NET and SharpDevelop were ported, so there is proof of its power.

Don't get me wrong, there are some difference, and some specific things do not work, the most notable I can think of is split containers, but the majority requires no modification between platforms. There is also a nice VS add-in that gives you a "Run in Mono" option, and a tool for testing Mono compatibility.

Here's a link to the site.
http://www.mono-project.com/Main_Page
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

May 16, 2012, 02:13:33 am #3 Last Edit: May 16, 2012, 02:22:04 am by Blizzard
I can't exactly remember why we chose Python over .NET, but there were a few good reasons. I don't remember if we considered the fact that we had Mono at our disposal. I think one of the reasons was plugin development since all you had to do was write a Python script (which is similar to Ruby in syntax) and just insert it.

Extremely late in the development? Maybe not. I don't know how the GUI system of Python that we're using works right now, but if there are similarities, porting the code is not that difficult. It's up to you guys.

Regardless, though, maybe we should port it at least after the editor has been finished. It would be good to refactor and restructure some things anyway, especially when I join the editor party.

EDIT: I found it. We had RMPY as code base initially. http://forum.chaos-project.com/index.php/topic,8927.msg137466.html#msg137466

Now, If forgot what happened to that and why we couldn't use lots of the code.
Also, F0, what about Gemini?
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

ForeverZer0

I still have all the source for Gemini. If we did choose the to use Mono, I would need to look into Scintilla.NET's compatibility. The biggest factor that contributes to .NET/Mono third-party compatibility is the use of P/Invoke, which I am relatively certain Scintilla.NET makes use of.

I have actually already devised a plugin system that works by simply dropping a .NET assembly into a folder and using Reflection on it to use any classes in the main editor. I simply made an IPluginClient and IPluginHost interface that needs used for a plugin, where all it takes to allow any form to be used is by adding "public IPluginHost Host { get; set; }" to the class. IPluginHost exposes all the games data classes that are being modified in the editor, therefore creating a plugin is quite simple for anyone who knows .NET. The plugin system is tested and works fine, all plugins are registered in a static Registry class, and can be called via it. Any any information you need is stored in a "Plugin" class that exposes the Assembly, AssemblyName, etc. instances, and the windows are created by using the Activator class .

		private IPluginClient GetInstance()
{
IPluginClient instance = (IPluginClient)Activator.CreateInstance(_type);
instance.Host = _host;
return instance;
}


The "_type" is found by using some simple Reflection and reading a file compiled with the dll, which simply lists the name of the class and the "public" name of the class that the user will see, such as "Enhanced Item Configuration" or whatever.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

Lol, I use an almost identical plugin system in Class Tools.

How much would Gemini help us out here? Would be basically an almost finished ARC editor, something along the lines of the current editor (70% done) or would we still need to a lot of work (let's say < 25% done)? And what are you using Scintilla.NET for? Is it the Ruby source parser?
Worst case, we may have to manually load stuff from a C++ Scintilla DLL. C# can do that, I'm just not sure whether it would work just like that.

Ryex, what do you think?
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

ForeverZer0

Scintilla.NET is simply a .NET wrapper for SciLexer.
The script control for the current editor is pretty much done already, just need to go over it and clean it up a bit and fix a few things with Ruby syntax parsing, specifically the "def self.whatever" the "self' does not colorize, and range operators take the color as if they are floats instead of operators. It really wasn't too difficult making it, I simply applied what I learned about SciLexer when making Gemini and basically just made a Python port.

I did a little looking around, and it appears using Scintilla.NET in Mono is not really a viable option. There are a few other syntax libraries out there for this, but I doubt any are near as rich in content. This might prove to be a pretty big obstacle, since our options would be down to either creating are own from scratch or searching around to for another library, which are not very common, especially when you throw in the fact that it needs to be Mono compatible. Creating our own may not be as hard as it sounds, since we need only have support for Ruby syntax, but it will still be a challenge.

Another major hurdle will be the docking library. I have personally used Dock Panel Suite from sourceforge, which is absolutely perfect for a VS like environment, and VERY simple to use. It can be used commercially and everything, but doesn't work on Mono. There is a "Lite" version of it that disables the drag-drop feature on non-Windows platforms built specifically for Mono, but that sucks, and it would simply push people to use Windows, in which case what is the point of all the trouble making it cross platform. There is wx.NET and GTK#, both .NET wrappers for creating GUI's but neither off use of VS's designer. GTK# is used my MonoDevelop, "the Mono IDE", but it is very inferior to VS. I am unaware of a wx.NET (a .NET wxForms wrapper) that allows use of a designer, but it basically allows you to write wxForm apps with C#. I played with it a bit, and the it works basically the same as what we are doing now, though you are using C# instead of Python.

And here is another option, though this may be unrealistic for a first release: Screw cross-platform support, and built separate editors. One for Windows, one for Linux, etc. Make a badass editor for Windows using all the available libraries and native .NET (not Mono), and then make another using GTK (which has a native docking library), using all Linux has to offer in awesome libraries. The core functionality can be pretty simple to port and borrow from one another, the actual code for the forms would just be totally different. This is actually my favored choice, I just don't expect much support for it, so I never really brought it to the table. I am a .NET programmer at heart, and I personally feel that is where I can excel at, and really enjoy doing it at the same time.

Pros:

  • Would ensure full platform compatibility

  • Would eliminate limitations imposed by the need to stay cross-platform

  • I would actually enjoy writing code for it instead of constantly researching (This is my selfish reason ;) )



Cons:

  • A lot more total work

  • A LOT more total work

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Ryex

put it this way, The editor is so close to done right now it's scary. I have to fix the panel dispatcher to track the last active pane so it know where to dispatch the next panel and where the shadow panel should be. I have to add the brush system to the map editor. and I have to link all the controls in the database to actions to enable editing of data. there are a bunch of small things to polish off after that but then it's done. and we can instantly release versions for all platforms. (provided I can get everything to build on mac/make sure building in a mac VM is good enough for real macs)

oh ya, and the event editor too, dam.

That's how close we are.

Anyway, that's how close we are to change languages now even with Gemini and F0's plugin system we would lose SO much.

now I'm totally biased her as I've invested 2 years of my life and a great deal of thought and effort into getting the frame work for this editor built plus I actually have very little experience in c# and .net.

frankly the first two "pro's" you listed don't exist as far as I see because we already have full cross-platform compatibility and the switch would put me in your shoes with python in .net.
and so you know I'm constantly researching while I code you can't honestly be expected to know every part of the standard library for a language or package.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

I concede the first pro may not be relevant since we do have cross-platform compatibility, I just know what my "dream editor" would be like, and I cannot do it using wx. I can, and for some parts already have, done some very cool things with .NET that are not realistically possible with Python. I admit, it is much of what I have been doing in my absence from working on our shared project. I really didn't say anything, I kinda see it as a "betrayal" to you guys if that makes any sense. I should have been working with you, not by myself when our end-goal is the same. I admit that my opinion is biased as well, I never really cared for the Python editor from the start, but I didn't speak my mind then, so the responsibility is solely my own. Ryex had an awesome start that we could build a base off of, so it was a good decision to keep going with it, I will not argue that one bit. It just never was my original dream when I made that first post long ago and I feel seriously hindered in my work.

The primary point of this project is to enjoy ourselves with a challenge in the hobby that we enjoy. We all like programming. It gives us enjoyment. That may sound strange to some people, but we all understand that. We all have our preferred languages obviously, and enjoy using one over another, which I admit a large part of my offer is based on that fact. I don't really relish Python, and I have a hard time staying interested in this. The problem is, Ryex will obviously feel the same about switching to .NET, which is not fair to him, hence my apprehension at bringing this subject up, especially so late. Ryex, I understand everyone does research while programming, but it is for a language you have interest in and enjoy working with. It is not the case for me. I don't believe it to be fair to you to ask this of you, I would feel the same as you if the situations were reversed, so I don't hold your opinion against you one bit. I expect you are even peeved it is being considered, I would probably be.

I have another proposition. I will respect you two's opinion on the matter, it is merely a thought: Allow me to create a Windows version of the editor. I am quite capable of coding fast in C#, and I am confident I can be up to the current editor's progress in a week or so. I already have some larger portions of it done, most in small other projects I would only need to port, such as Gemini to an integrated script editor, an interactive chart control, curve generator, plugin system, etc. I have started numerous projects for this exact reason, scrapped them then started over, and I now have a good framework formulated, and even half-implemented with great success.

This scenario, although gives Ryex more work to do on the Python editor, would make nothing a waste. The current editor would be used with Linux and Mac, while either could be used on Windows, whatever their preference. This may seem like somewhat of a redundancy, but the majority of users will be on Windows, and I know I have the ability to do some really neat things that I either cannot or do not know how to do with Python.

IronRuby is makes a non-issue of serialization, I already have plenty of experience embedding it within a C# .NET application and using it. The obstacle I know I would have that I have not experimented with is the map editor. GDI+ may not be fast enough, and would like to avoid XNA for the editor. There are OpenGL .NET libraries if need be. I would have to look into that if we went this direction and GDI+ wasn't enough. My screenshot application I made could successfully render the maps, change tone dynamically, etc., so it may be a non-issue.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Ryex

I'd really rather you didn't do it right now... also if you did that you would need to write a .arc serializer and deserializer for .net. unless of course your going to keep all the data objects Ironruby side and use the ruby version.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

IronRuby is capable of reading/writing native Ruby objects normally, so it is already a serializer/deserializer. You only need to require the scripts and load the data. I can actually handle all the data inside the editor as the Ruby object that it is, and not need to convert it to anything else. You do loose the intellisense when dealing with "dynamic" objects, but it will only apply with the basic data classes used in ARC, so its not a big deal.

There is a bug with IronRuby's Zlib library. It can inflate a string just fine that was compressed with native Ruby or IronRuby, but native Ruby cannot inflate a string compressed by IronRuby. I found a workaround by using a different Zlib library, and made a bug report on IronRuby's site, but I don't think its been fixed. Development is pretty slow for it.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

First off, ZLIB is not a problem, .arc does not use ZLIB.

I prefer .NET over Python as well. I admit that one of the reasons I stayed mostly on the engine was because I didn't want to familiarize myself with the Python libraries as well. Besides, there was a lot of work on the engine to be done anyway. Even while working on the engine I had to do a lot of research as well. Imagine how much time I've spent researching DirectX color blending, pixel shaders, render targets, etc. Not to talk about the Ruby related stuff.

As for the organization further on... If the editor is that close to completion, we should make use of that. Maintaining 2 editors is a pain and not an option. So this is how we are going to do it:

1. The Python editor will be finished. Ryex can take care of the big stuff and F0 can do coding on the side. Obviously Ryex will have to define what F0 is supposed to do.

2. After there are no more of these "small tasks", F0 will help Ryex finish the rest of the editor. This will include research, there is no way around it.

3. This will be ARC - Legacy Edition.

4. For the full ARC engine, we are obviously changing things. I will create a branch that we can maintain after ARC - LE has been released for potential bug fixes and small additional features on both engine and editor.

5. When development for the full ARC starts, I will first create a design document about how the engine will work. I can bring a lot of game development experience into this and experience with the libraries we are using in the background (e.g. AprilUI). We will discuss things and make a final design document for the engine.

6. The editor can't stay as it is. New engine = new editor, there is no way around it. Of course we will be able to reuse lots of code from the LE editor.

7. This is the point where we will decide if we're going to switch to .NET. The requirements for .NET are that everything has to be compatible with Mono. If we have some super-cool libraray that uses some crazy features, but doesn't work in .NET, screw it. Windows.Forms are powerful and easy to use, there is no need for us to use some exotic libraries just because they have a few fancy more features that we don't really need anyway. This will obviously require more research work.

Do you agree with this plan? We are close to a release. If we decided to switch to .NET now, we would be shooting ourselves in the foot and basically make the mistake everybody else made when trying to make a new RM: They learned so much during the development that they realized that their design could be much better so they scrapped everything and started from scratch which sometimes included a change in development environments such as IDE or programming language. Let's not make that same mistake. After we have finished LE, we will worry about refactoring, rewriting and other stuff.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

I'll go with it, but it doesn't really change anything.
All the "big stuff" is and already has been pretty much done for some time. There are just loads and loads of small things left to do. These small things add up to be even more than the big things. None of it is especially hard, its just a whole of coding tedious stuff.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

Do you really think you could get Gemini to a point where it would be basically done about the same as RMPY in only a week? Besides, there's still the problem of a good set of libraries that work on Mono as well.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

ForeverZer0

May 17, 2012, 12:31:31 pm #15 Last Edit: May 17, 2012, 08:08:43 pm by ForeverZer0
I already have a main docking editor, Ruby embedded, Scintilla embedded, chart controls for parameters, a working plugin system, and some other minor utility classes.  I can basically copy-paste most of the Gemini code to have a nice feature-rich script control. The interface looks and works like VS, windows being able to be moved and docked as the user wishes. I have some other projects with code that is a good start on a tilemap editor, though I am not gonna say it is near complete. It can draw a RMXP map with events and change tone and what not, but there is nothing done for drawing interactively yet. It would probably take me about a day or so to get everything together in one project, and a few more to create all the forms used in the editor. The only wildcard is the tilemap editor.  I'm unsure what issues I may run into in regards to performance.

EDIT:
Using much of Gemini's code, I got a nice script editor window working good.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Ryex

Ugg,  ok. I know the answer to this question could invalidate 2 years of my work in python. but exactly what state is you editor currently in? screen shots or a dev build would state my suriosity.

and most importantly, does it work under Mono?
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

First, nothing is invalidating 2 years of work you did. This is a about a one month project I have made, and as already stated, is only serving as a Windows-based editor. Full Mono-support is going to be harder to achieve than I anticipated. For the following reasons:


  • Scintilla.NET heavily incorporates P/Invoke, which is a big no-no when trying to create something Mono compatible. Mono is currently not supported, without any apparent plans on it ever being. A syntax-highlighting library to parse Ruby COULD be created from scratch, or another could be found, but both of these options would be a major setback.

  • The docking library to create the VS style UI also utilizes a lot of P/Invoke. It is supported in Mono to a degree, but nothing I would consider being usable for what we want the editor to be.

  • I am currently using XNA for a few different controls. That is obviously not possible on a non-Windows platform. There are a number of OpenGL .NET libraries around, so it would probably not be the biggest deal in the world, but I have no experience with them personally, and have not looked into Mono support of them either, but suffice it to say, dropping XNA would also be a setback.

  • Split-container controls. Last I looked, Mono does not have these, and the editor is full of them, hell, even relies on them to achieve certain layouts. I suppose a control could be custom made, but I am sure it would not be near as smooth or easy as the .NET build-in one. Nether would I relish changing every one of them.



I just had a huge reply I wrote here, and lost it all because I accidentally closed Opera. What you see above I had on the clipboard from switching from quick reply to the full editor. Ugh.... :facepalm:

The long and the short. Yes, I have a 80%+ done .NET based editor that I have been working on diligently for about a month. It currently doesn't even come close to Mono compatible, either. I understand this is not our grand plan, but it is results, which neither me nor Ryex can claim we have made any ground on in a long while. The editor is what people want to "see", and it doesn't take me to point out the fading interest in ARC due to these lack of results. I am pretty sure that given another month, I can finish and tweak what I have into a full, stable, and feature-rich ARCed that will be ready for release. Although it will obviously only run on a Windows platform, this should at the very least "tie over" people. Using Windows will cover the overwhelming majority of interested users. Are target users are RMXP fans, which is a Windows application, so its safe to say 95% or more of interested parties have no problem running on Windows.

Either way, it is nearly 2:30 in the morning here, and I am heading to bed shortly. I can commit what I have done tomorrow. I would tonight, but I have a lot of test stuff that should be removed before adding to a shared folder, it would serve only to confuse, and not really demonstrate a lot in its current state. I'll prepare it and upload first thing when I get back on my PC.

I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

Hm, since Legacy Edition will have a revamped Python editor anyway, I think releasing a C# editor for Legacy Edition is an acceptable solution, especially if you consider the fact that we will done OH MY FUCKING GOD WE WILL BE FINISHED WITH LE! :'D
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

I'm ok with releasing a C# editor for legacy edition too. just promise me that all my work with python won't go to waste as it's still the best option of cross platform version of the editor.

I even figured out how to get the editor to memorize layouts and restore them just 20 minutes ago because I was thinking about it after reading you PM again. it's actually ridiculously simple now that I have the panel manger complete, it's a matter of caching the PaneInfo objects and then saving that cache to a file and loading it again when you want to use it, and dispatching the windows using the cached objects. haven't tried it yet but in theory it should work.

I'm still setting up my new computer so I don;t have my development environment up yet but I'll be back in full development mode soon.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />