Source Code for Illumination 4.x Series Now Available

The full source code for Illumination Software Creator 4.3.2 (which is functionally identical to 4.3.1) is now available on GitHub.

Incredibly important note: This is not ISC 5.0, which is an entirely different code-base.  More on that below.

Now.  For those interested — time for a history on the development of Illumination Software Creator (aka “ISC”).

In the early days (way, way before “1.0″) ISC was prototyped in a number of different ways.  The very first functional version was created using Lazarus (which is a, most excellent, IDE for building cross platform apps using the Free Pascal Compiler).

This version was, ultimately, scrapped.  Not because of anything that was wrong with Lazarus or Pascal (both are very capable of building a robust app, like ISC).  No.  This version was scrapped because the overall design was wrong and the workflow needed a major overhaul.

The second version of ISC was prototyped in Flex (ActionScript) as an AIR app.

This version was scrapped almost immediately.  For many reasons.  Partly because the design was, again, not what it needed to be.  And partly because Flex made me grumpy.

The third version of ISC was prototyped in RealStudio.  This is the version that ultimately became “ISC 1.0″.

[Notice I'm not exactly loyal to any single language or SDK?  Good odds that, if I had needed to re-do the prototype version of ISC again it may have been in Smalltalk the next time.]

Over the course of time between 1.0 and what we have now as 4.3, many changes took place “under the hood”.  And many, many branches were created.

During that period of time the code responsible for drawing the UI chart was replaced with a new, super-fancy charting control.  Then scrapped and replaced with a modified version of an open source (CC) charting class.

Even more importantly — the underlying logic responsible for code generation was changed twice.  The first major change was to utilize the “i” language (“i” standing for “Illumination”… what later evolved into the “Lunduke Language” and SDK).  The “i” language was a middle-layer that sat between the visual layout and the platform specific code.   In 4.2 this was changed back to an older system (that was previously used in the 1.x series) due entirely to time constraints and a few key fixes that would need to be backported from the blossoming Lunduke SDK into the older “i” language (there was no Realstudio implementation of “Lunduke”… only “i”… and doing so would have simply taken too long for too little benefit).

Over time there have been branches for working on a variety of different platforms and ideas.  Some of these made it into shipping versions, some didn’t.  If you look through the code you can find ghosts floating around here and there from some of those glorious ideas and platform targets.

Now.  By the time ISC 3.0 shipped it became very clear that some changes needed to be made.

First and foremost: I wanted to be able to run ISC on more platforms than RealStudio allowed (Linux/Mac/Win).  Ideally I wanted to be able to run ISC on any platform that ISC could build apps for.

I also wanted to build ISC on top of an open, easily modifiable platform that I could have a bit more control over.  RealStudio is a perfectly good development tool (for the most part)… but it’s tightly closed down and the licensing has become more and more restrictive over the last few years (in fact ISC 4.3 must be built with Realstudio 2011R3 due to licensing issues on later versions).  So that just simply had to change.

Thus the Lunduke SDK was born (providing extreme cross platform-y-ness and a foundation that was completely Open and flexible).  And ISC 5.0 was begun, from scratch, written entirely in the Lunduke SDK.  Those will be checked into GitHub as separate projects.

ISC 4.3.x is in GitHub as the legacy version of ISC.  That said, I am very open to merging new features and fixes into ISC 4.x (as I know many have expressed interest in doing).  I, personally, will be putting my efforts into ISC 5 — but I have no qualms at all about people diving in and building up ISC 4.x further.  I will even assist where possible and help with merges, testing, etc..

So.  There you have it.  ISC 4.x is a big, beefy project.  Large portions of it are very easy to follow and read… but it’s still a big project.  If you are interested in working on this, and have any questions, the forum is the place to ask.  I will do my best to answer them in there.

And, just as a super-duper-subtle reminder, the development of ISC (and everything else here) is funded entirely by support from people like you.

Share Button
  • Javier

    Yes!! After 788 days, 16 hours and approximately 30 minutes, for I saw the LAS episode three weeks after it came out, my dream (one out of many) has finally come true!!!
    http://www.jupiterbroadcasting.com/1814/the-future-of-software-development-the-linux-action-show-s11e07/
    Illumination Software Creator is open source and under the GPL.
    Thank you Bryan, you have this stable donator for a year as minimum!

  • manny

    awesome news !

  • Javier

    Yes, I am weird. XD

  • http://clems-ramblings.tumblr.com Daniel Clem

    Can’t wait to see 5.0!! I hope my project from 4.3.1 transfers over alright. Its getting to be REALLY big. And I’ve got about 30 or more variables. And still growing. And eventually I’m gonna have more than 50 to 100 images to load in canvases.

    Will this cause performance problems?

  • Javier

    @Daniel
    As I have said, I don’t think it will cause performance issues, just a long start up.
    Daniel, sorry I haven’t got the time to reply to you! I’ve been very focused in getting packaging done this week and my progress has been terribly slow. Hours and hours reading on distutils and experimenting in quickly, and a few more on debian packaging, and I still can’t get the .py file and images to go into the /opt folder. (I wonder how Bryan did it for his software.)
    Python has its own building for distribution method, once that’s working it can be easily combined with debian packaging. The problem is Python does not send files to /opt by default like the Software Center asks. I suppose I’ll have to combine both methods in a least ordinary way to get all files in their proper places due to the particularities of my software, and I not being able to create a setup.py file that places files in /opt.
    All that and a big video project I’ve been editing this week, for that’s one of the many things I do best, have taken over me this week.
    I will get back to you on Monday! Please pardon my delay!

  • securezone

    SUPER AWESOME. YOU ROCK!!!!! WOW!