Too much travel and conference fun, too little blogging:
I was invited to present a keynote at ACM ICFP 2005 in Tallinn, Estonia at the end of September. The very kind program comittee was unanimously interested in me as the ‘where the rubber meets the road’ speaker. I hope I delivered; I still have tire marks on my back from the Netscape 2 days.
It was an honor to speak and attend, and I made some good connections and introductions. Among these was Autrijus Tang, who is a hero in my book for promoting both Perl 6 and Haskell in one fell swoop. Functional programming is on the rise, and I’m glad that JS is playing a small (but very widely distributed) part.
While there, the Skype guys were nice enough to have me out to dinner — I hope to reciprocate when they’re in the bay area.
The old town in Tallinn is delightful, full of charming architecture from various eras going back to the high Middle Ages. I’m planning my move already (half-kidding).
After that came Web 2.0, which was a blur of VCs, old friends, and new companies. Everyone noticed the bubbly atmosphere. Mitchell was in fine form in a kind of interleaved interview titled Can Open Source Stay Open?
- Bringing Edition 4 back toward the current language, so that prototype based delegation is not a vestigial compatibility mode, but the dynamic part of an object system that includes classes with fixed members that cannot be overridden or shadowed.
- Allowing implementors to bootstrap the language, expressing all the meta-object protocol magic used by the “native” objects (ECMA-262 Edition 3 section 15), including get/set/call/construct and control over property attributes such as enumerability.
- Adding type annotations without breaking interoperation of existing and new editions, in support of programming in the large — which is needed more and more in XUL and modern web applications.
- Fixing longstanding problems that bite almost every JS hacker, as I’ve discussed previously.
Our intention is to finish by the end of next year, and to implement and test interoperation along the way as much as possible. The Macromedia folks are quite far along in their implementation of a derivative of Waldemar’s Edition 4 draft, called ActionScript 3.
At the same time, and while also slaving over a hot Gecko 1.8 / Firefox 1.5 stove, I have been working with Mozilla leaders, especially shaver and other drivers, on roadmap-level plans for the next year to 15 months.
These plans build on bottom-up planning from module-sized projects such as the move to Cairo graphics as Gecko’s new graphics substrate, the Python for XUL project, and the XULRunner project. We aim to balance the need to ship Firefox releases that innovate quickly in user-facing ways with the longer cycle time required to uplift the web platform with better graphics features and content languages in Gecko 1.9.
The fruits of all this planning, in the form of a coherent draft overview containing links to project and wiki pages, and a schedule and branching plan for everyone to review, will be pushed out to http://www.mozilla.org/ imminently. The old roadmap page will contain at least links, if it doesn’t beome a redirect. Stay tuned.
I announced XUL support for Python at ETech to cheers, and now Mark Hammond has begun delivering the goods. See the DOM_AGNOSTIC_BRANCH for his work to enable Python (and other languages, but Python for sure, and other languages need their own champions to do some work) to be used when writing trusted XUL applications and extensions.
One of Mark’s first testcases, slightly abridged:
for attr in "document parent top scrollbars name textZoom scrollX scrollY".split():
val = getattr(this, attr)
except (xpcom.Exception, AttributeError), exc:
print "FAILED to get attribute %s: %s" % (attr, exc)
print attr, "is", val
print "Scrollbar visible =", this.scrollbars.visible
promptService = xpcom.components.classes["@mozilla.org/embedcomp/prompt-service;1"]
promptService.alert(this.window, "title", "Hello from Python");
A more recent example showing how to mix scripting languages:
// Some XUL that uses the default scripting language, JS:
<button id="but_js" label="click for js"
oncommand="dump('hello from js\n');"/>
// A XUL overlay that uses Python by default:
<overlay ... scripttype="application/x-python">
<button id="but_python" label="click for Python"
oncommand="print 'hello from Python'"/>
Python for XUL will be available in the Mozilla 1.9 milestone time frame, when the DOM_AGNOSTIC_BRANCH is landed some time this calendar year for sure, but then only in alpha releases and trunk nightly builds. The next major Firefox release based on the 1.9 milestone (Firefox 1.5 is based on the Mozilla 1.8 milestone) will include Mark’s work — but not a C-Python environment by default.
How Windows end users, and others who may not have Python installed already, will get it along with XUL that requires it, remains a problem to be solved. We have net stub installer technology, and now with Firefox 1.5, a patch-based incremental update system. I predict this problem will be solved quickly as great Python-based XUL extensions to Firefox, and new XUL applications built on Firefox or XULRunner, emerge and gain users.
Given evolving JS, why Python? Simple: different programming languages, of different ages, have their strengths, and one of the greatest strength of any solid language is its community. We want to support Python as well as JS for XUL scripting in order to engage a large, creative community of hackers that is mostly disjoint from the web-standards-savvy XUL hackers who are already engaged with Mozilla and Firefox.
We aim to broaden the appeal of our platform in several ways, and supporting Python for XUL is one achievable way to do that, thanks to Mark’s work back in the days when he was employed by Active State, and now that we have him engaged again for the Mozilla Foundation.
Back in my February 2004 Developer Day slides, I promoted the idea of using Eclipse to create a XUL application builder, with direct-manipulation graphical layout construction and editing, project management wizards, etc.
Although a few people expressed interest and even did some hacking (the MozCreator project being the most conspicuous example, although not Eclipse-based), no one actually created an Eclipse project and built on its Graphical Editor Framework to realize a XUL app-builder.
The good news this week is Open Laszlo and IBM releasing the Eclipse IDE for Laszlo. LZX is cool, and similar in spirit, and in many ways in flesh, to XUL.
So the thought occurs: why not patch the Eclipse IDE for Laszlo to support XUL as an alternative target language, and Firefox (or any new-style XUL app, soon enough unified via XULRunner) as the target runtime? Any takers?
I ran across an old posting from dbaron about how CSS’s 2nd generation still can’t do simple box layout needed for UI, which means that the web is full of hacky table tags. XUL box layout, which appears to be headed for standardization in the CSS working group, is a known solution that should be available to web app builders. Mozilla supports XUL, and Safari has XUL box layout support via CSS extensions.