open komodo and the code
Yesterday we (ActiveState) announced Open Komodo, an open-source project seeded with much of the core of Komodo Edit and Komodo IDE with the goals of produce a platform/framework for and (codename Komodo Snapdragon) an IDE for client-side open web development.
That’s a mouthful. Shane and David have done a good job giving some wider perspective on what the Open Komodo project could mean (if all goes well). David went so far as to invent new language to make his points.
Some quick thoughts from a coder’s perspective:
The source will be available in a Mercurial repository in (quoting Shane paraphrasing Mike Shaver) “Two F**king Months!”. Early November — or earlier if we can.
Komodo is a Mozilla-based application with the added heavy use of PyXPCOM for much of the core logic. That means the app comes together like this:
- Get a slightly tweaked mozilla build (C++, JavaScript, XUL).
- Get a slightly tweaked Python build (C).
- Add a bunch of core logic (Python). For example, the guts of Komodo’s Find/Replace system is written in Python — using Python’s unicode-aware regular expression engine.
- Add Komodo chrome (XUL, JavaScript, CSS, DTDs).
What this means is that to work on and add significant functionality to Komodo, all you tend to need to know is XUL, JavaScript and Python. From early on in Komodo’s development we’ve felt that this is one of Komodo’s aces in the hole: developing in the dynamic languages is so much faster. I remember David Ascher making the comment way back that if Subversion had been written in Python, it would have been ready years sooner. And now two of the primary DVCS, Mercurial and Bazaar, are written in Python.
Komodo uses the same extension mechanisms as Firefox. It is easy to build a .xpi to add functionality to Komodo. We really hope that a community of Komodo extension authors will develop.
Komodo builds and runs on Windows, Linux and Mac OS X. Given some work there is little reason the Open Komodo code base couldn’t be made to run well on Solaris, BSD, etc.
If any of this sounds interesting to you as an open-source tinkerer, then give Komodo Edit or Komodo IDE a try. The first app that will come out of the Open Komodo project (Komodo Snapdragon) will look and feel a lot like them.
In subsequent posts, and especially once the source code repository is up, I plan to blog here about Komodo’s internals.
September 7th, 2007 at 8:24 am
It’s great to see this information flowing out already. You make it sound easy but when I tried a while back to get a python enabled build of Mozilla going I hit so many problems with build/runtime python dependencies issues, largely due to using msvc 8 (the only free version). It appears from bugzilla that these issues may be resolved and perhaps I should have tried harder/longer. The other problem I hit was that lack of development tools such as debugger (venkman for python) and dom/css inspector etc. I guess that is sorted with Komodo too? I’m keeping a keen eye on developments as I would be interested in using XUL + SVG + python with DOM scripting and events. If you provide good docs and tools so it’s easy to get going and pick up your experience you could have a real winner. The only other concern I have is that Python scripting on SVG/web pages needs to run in a sandbox and I’m not sure how safe rexec etc are in Python (in Martelli’s Nutshell book he says there are holes). Do you only use javascript for this? (Oh I’m creating an Assistive technology that is more of a rich client than a web app but want SVG and oter standards web deployable)
September 7th, 2007 at 8:41 am
Steve,
One of the important first things with Open Komodo will be in getting it all easy to build and dig into for others. We’ve struggled a lot to get all the Python build + Mozilla + PyXPCOM things working just right on all the platforms. One of the early things I hope we’ll be able to do it make that all easier so that other unrelated XULRunner-based apps can follow suit.
Agreed that all the building is still way too hard.
Regarding debugging: we don’t have a great story for debugging really. A long while back Mark Hammond, when he was working on Komodo directly, did have Komodo debugging Komodo, but we haven’t pursued that in a while. I look forward to people getting that going again though! :)
Python scripting currently is limited to PyXPCOM — i.e. just for XPCOM components. Mark Hammond’s current Mozilla work to make Python a first-class scripting lang in the browser along-side JavaScript (sometimes called pydom or nsdom) — i.e. — is not something we’ve yet played with. Mainly that is because the pydom work is on trunk (I believe) and Komodo is currently using the Mozilla 1.8 branch. As to security issues with pydom, I’d have to refer to the Mozilla dev docs on that.
September 11th, 2007 at 3:32 pm
Get a slightly tweaked mozilla build (C++, JavaScript, XUL).
Get a slightly tweaked Python build (C).
does this mean it won’t run with the vanilla spidermonkey/xulrunner/python that most linux distributions ship?
September 11th, 2007 at 3:55 pm
axel,
Not out of the starting gates (because we want to have this working really quickly), but the plan is
(1) To make Komodo a true XUL Runner app. Note that there are a lot of questions about how feasible it will be for XUL Runner apps to run with the generic XUL Runner base that a distro provides. Most current XUL Runner apps that I know about (those that get mentioned on planet.mozilla.org) tend to have their own patches against XUL Runner that haven’t yet made it into the core sources to fix issues specific to their app.
(2) Get Komodo working with more vanilla Python builds. On Linux, however, a shared build of Python is required and getting PyXPCOM to work in a running Mozilla instance is currently very finicky about placement of the relevant files. I don’t know if the Linux distros tend to do shared Python builds or if they do static ones.