ENIGMA Development Environment

As the final date for GSoC organizations to apply is approaching, I should say that we decided not to participate in GSoC this year. It was difficult to set up the current ideas list, which is the sign to us that it is not time. Josh hopes that we can participate next year, when ENIGMA advances more and hopefully, we have a new IDE. I hope that Josh finishes his current 5 projects that are unrelated to ENIGMA by next year and finally fixes everything. :3

DaSpirit there is no harm in putting it on GitHub. I wasn't even aware that anyone was still working on IDE projects any more.

Yeah, will do soon. I recently got swapped with school work, so might do at the end of next week. I hope you guys want to participate. I have so many warnings from everything that I didn't implement yet because I didn't deem it to be too important at the moment that are wrecking my OCD. :p

so much has been fixed, unfortunately some things broke in the process, I guess that is to be expected with an open source project run by contributors, sometimes certain things get broken and the person who worked on something that broke something else has no more time to fix it etc.....

When ENIGMA gets a build bot, this will not be an issue anymore. A good build bot will do unit and integration tests for each commit and be able to build the .zip files automatically. In fact, most open source projects already use Travis CI.

That IDE would probably be mine. Josh has been talking about Natural GM for quite a while. When I originally started making it, I've been constantly asking him for his opinion on my design.

So where am I now? Well, I restarted it on January, mostly because I was changing it entirely - the biggest change being the introduction of automatic memory management for plugins. Plugins will automatically clear their memory when they are unloaded and the IDE itself will have no problem when their memory is destroyed because the IDE stores memory as weak references (except for the systems where the plugin manager is closely tied to, where I can delete the memory easily). I have most of it figured out, and was hoping to work on it during Google Summer of Code. Plugin loading is currently functional (with the exception of the dependency system) and plugins will be able to create menu/toolbar items soon. Afterwords, I will be working on the project tree and editor API (which I will simply be cutting out from my old NGM version).

I am very pleased to hear that people want an IDE. My main repository is currently private on BitBucket, but I can put it on Github if people are willing on contributing to it. Robert has contributed it a few times already actually and I have a list of small tasks that he's been implementing. So yeah, are people willing to contribute by implementing small tasks while I work on the API?

Tasks such as "fix this" or "add these few functions" are not good tasks. We need to think of large tasks that would take three months to finish for someone who is completely new to intermediate to the topic.

What about C++14? :p

Anyway, I fully agree. What's the point of maintaining C++0x compatibility? I don't think there is any, or at least right now.

I like to run things by learning from the mistakes/failures/shortcomings of others. Game Maker doesn't work on Linux? I'll make mine work on Linux. G-Java evaporated from massive feature creep? I'll avoid features and focus on core functionality. This methodology reflects in all of my projects.

This is one thing I agree with. Having failed to make an IDE (and thinking about getting back on the horse every once in a while), I know that you really have to plan everything out.

I've been planning a lot myself recently (but not features, only the core). You have to think about how you want everything to connect to each other. What I mean, is that if your IDE can't do something else that another IDE can do, then it has a flaw. If you make your core API correctly, then you can add anything new with it.

Josh has injected the idea of plugins into me. If you make a plugin API and do it correctly, then you're technically done with the IDE, because everything else can be a plugin, separate from the actual IDE. Your IDE just tells everything how to interact with each other. If you were to figure out parts of your API later, you may have to rewrite large portions of your code to get the results you want, wasting a lot of your time.

DX12 is just doing the same thing AMD's Mantle API is doing.
http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/mantle

OpenGL "Next Generation" is in the works as well. They're planning on deprecating all old OpenGL versions and starting anew in favor of an API more like Mantle.

I think it's overhyped.