It has been a busy week while anticipating JSConf this weekend in Berlin. This is going to be a great event, and we're happy to be present there with four members of the qooxdoo core team at 1&1, including a qooxdoo-related talk. But now to some framework activities this week:

Part handling

A conceptual bug in the part handling of the generator was fixed that surfaced when using a lot of parts with a lot of packages. It occasionally hit when packages were merged by the generator, to reduce the number of files that constitute the application. It turned out that the merging process didn't heed the load-time dependencies of those classes it was moving around. Consequently, the solution was to track load-time dependencies between packages when doing the merging. A verifier was added to the generator that checks all parts are complete (wrt. class load-time dependencies) at the end of the merging process.

bash: Tab Completion

A small bash script was added (tool/bin/generator_compspec.bash) that provides tab completion for generator.py invocations. So if you're using bash, either on Linux/Unix variants, Mac OSX or Cygwin/Windows you can use this to type in a project folder ./generate.py <TAB><TAB> to get a list of available generator jobs, or the completion of a job name after a few characters. It's not sophisticated but might help some people working with the command line. Source the file in your .bashrc or .bash_profile to get it working on your shell.

Bugs

For a complete list of bugs fixed during the last working week, use this bugzilla query.

Google Closure

Most likely you've already heard the latest buzz: Google released a set of tools under the name "Closure". It basically consists of four parts: Library, Compiler, Inspector and Templates. To summarize in their own words it's "a broad, well-tested, modular, and cross-browser JavaScript library" that comes with "a JavaScript optimizer that compiles web apps down into compact, high-performance JavaScript code". Sounds familiar?

So lets welcome (yet) another JS library. Just the fact that Google is releasing such a library guarantees a lot of attention (see this section as an indication). Unlike the many widely-used low-level libraries (jQuery, Prototype, etc.), this one is a more comprehensive library with (at least) some tooling. We'll see how well it fares compared to existing - "modern" if you will - libraries/frameworks like Cappuccino, ExtJS, SproutCore, YUI and, of course, qooxdoo. From looking briefly at Google Closure, it somewhat "feels" like Dojo. While there are some sweet spots in Closure (e.g. some of the advanced optimization features of the compiler), frankly, I was rather disappointed. Given five years of qooxdoo exposure, I'm biased for sure, but unlike the unavoidable ecstatic commentors in the blogosphere, there doesn't seem to be all too much new, powerful or elegant stuff in Closure. What is your impression? Many of the modern JS frameworks mentioned above seem to have more individual - if not unique -highlights than Closure apparently does, not only when you look at typical GUI features. YMMV.

IMHO it should be an advantage to qooxdoo - as it is for all JavaScript-based application development - that Google is present now not only with end-user apps, developer-centric web services or its Java-based GWT, but also with a significant piece of open source JavaScript technology. Particularly the tooling aspect will gain much more focus among existing and potentially new web application developers. When compared to the other current JavaScript frameworks the integrated tool chain of qooxdoo is one of its strong points, besides a state-of-the-art GUI toolkit for creating rich internet applications. With JavaScript-based applications being (and even more so becoming) an extremely successful technology, qooxdoo is well-prepared and a mature solution for many challenges, don't you agree?

The road to qooxdoo 1.0

Talking of maturity this is to remind you of qooxdoo's ramp down towards the 1.0 release, which is still planned for the end of the year. During the last weeks, actually for several months now, a huge number of bugs have been resolved, enhancements implemented, larger topics and inconsistencies in the framework addressed. The testing infrastructure, that was established and improved in the course of the year, became a valuable tool as it helps ensuring a sufficiently high level of software quality. Among all the regular development activities, which we're able to pursue ourselves as full-time framework developers, the input and support of the community, contributors and committers naturally is of great importance. This is especially true for the challenges when approaching a 1.0 release.

We'd like to ask for your dedicated help and support during the next few weeks. For instance, if you encounter issues and inconsistencies that to your knowledge (please scan bugzilla first) aren't recorded or addressed already, please let us know. Pay special attention to all API related issues, as it gets naturally much harder to address those after a 1.0 release, which is supposed to gain much from API stability. Clearly, not all open issues can be resolved for qooxdoo 1.0, or any release after, but we're focused on addressing the most important and relevant defects as well as the most significant enhancements in a reasonable manner. Again, when reporting real defects, or requesting enhancements, please choose qooxdoo's regular bugtracking over the mailing list. This usually guarantees for the most effective and least redundant workflow without cluttering up the list.

All assignees of a bug are asked to review the issues soon, possibly working closely with the reporters in resolving them. If you happen to be the reporter of a defect or an enhancement, or otherwise interested in the issue being resolved, please feel free to approach the current assignee and offer your help. We regularly perform bug triage to never have a real defect unassigned. That doesn't mean that the assignee is going to work on such an issue promptly. If he/she does or plans to, the status is supposed to be switched from "new" or "reopened" to "assigned". See the bug handling documentation for more info. If you're in doubt, talk to each other.

In the next few days we'll also prepare for the 1.0 copy of the qooxdoo manual. Like the rest of the homepage it is just a wiki, so after a simple registration you can collaborate in improving the existing documentation. Everybody is encouraged to review the current articles, i.e. finding, reporting and preferably enhancing/fixing the docs. Language corrections by native English speakers are appreciated. Much of this also applies to the API reference, which is generated from the JSDocs of the qooxdoo code base. If you identify issues that should be addressed, at least report them, at best fix them yourself. It would make sense to carefully go through a current SVN checkout and review individual namespace packages. After you make the changes to your local copy, a patch file can easily be generated and attached to a corresponding bug report. We'd take care of applying your API corrections asap. Does anybody feel like participating and help coordinating efforts around the wiki and/or API docs?

When preparing the wiki for 1.0 in the next few days, we'd also like to correct a milestone misnaming: being in the ramp down for qooxdoo 1.0 for a while now we decided to rename the formerly planned (but then postponed) 0.9 release to a 1.0-beta pre-release. While there are certainly pros and cons of having another "formal" major release, this renaming matches best the status and progress of previous and current framework development. As with any release, beta or major, we'd appreciate you tried this code base at the time of availability, planned for end of November, in order to spot any open issues. This even more applies to SVN trunk, thus anyone of you that is able to run his/her qooxdoo apps against a recent trunk version, is encouraged to do so. Of course, we can't expect you to do this for your production code, i.e. in its deployed version, but often it might not be much effort for you to have a parallel version built and tested against qooxdoo trunk as well. Besides helping framework development, you'd also help yourself and your investment as being close to the qooxdoo trunk helps you to notice and react to any changes and regressions you'd not be comfortable with in a 1.0 or after.

It would be great if you kept an eye on the mailing list to help other community members with their problems and answer their questions. On a daily basis the members of the core team use to take care of supporting the mailing list. With more users helping out others (and some of you are really excellent in doing so!), the time saved could rather be invested in framework development and the upcoming releases.

Think about all ways you could (even more actively) support qooxdoo. Thanks!