This year there's a special gift under the Xmas tree: qooxdoo 0.8.1.

It is quite a comprehensive maintenance release, with a lot of bugs fixed (about 250) since the 0.8 release. Many inconsistencies were resolved, carefully features completed and missing API added. qooxdoo 0.8.1 is recommended as an upgrade for existing 0.8-based applications, migration should be straightforward. This release should also be used by any new users getting started with qooxdoo.

The framework again proofed to quite easily adapt to the various browsers (and browser versions). Especially the state-of-the-art GUI toolkit (introduced with 0.8) and the framework's layered architecture allow for a wide support of all common browsers, even including the latest betas. This time with Google Chrome 1.0 adding to the mix of Firefox, IE, Opera, Safari, there's plenty of runtimes to choose from for your fully cross-browser qooxdoo application.

There have been many improvements for 0.8.1 - all over the framework. For more info please see the detailed release notes. Of course, there haven't only been improvements in the JavaScript framework part of qooxdoo, but also in the accompanying tooling part. For creating impressive rich internet applications (RIAs), one needs to have such a powerful developer tool chain. In 0.8.1 it got further tweaked and pushed, sometimes dropping or replacing inappropriate config options. Feedback to the ongoing progress in this field is always appreciated.

While it should be trivial to setup and use qooxdoo's tool chain for creating and developing applications, some potential users do not feel comfortable enough to do so, for instance when in a hurry evaluating frameworks. There should be an easier way to get a first impression of qooxdoo, at least of the JavaScript coding part. For that purpose a new interactive application was introduced with 0.8.1 called "Playground". It allows you to type in and modify code in a syntax-highlighting editor, and immediately turn that into a live qooxdoo application in the same browser window. There are some samples included as a starting point for your own experiments. Please keep in mind that this brand new app is not meant to be some sort of online IDE, it really just is a playground for some interactive qooxdoo coding experience. It certainly has its limitations and issues. Anyway, let us know if you like it and what could be improved.

There are now six demo apps that come with the framework and are also available online: Demo Browser and Playground for exploring qooxdoo code and features; Feed Reader and Portal to showcase RIA-style and low-level applications; finally API Viewer and Test Runner for either documentation or unit testing.

Download and enjoy the new 0.8.1 release.

Thanks to all the fellow developers, contributors and users of qooxdoo for their great support and collaboration!

Another weekly status report. It's for last week, sorry for the delay, we were mostly busy in preparing for a 0.8.1 release. Thanks to Thomas for his details about SourceForge and Generator:

SourceForge

We have revamped the download area of our project platform on SourceForge. qooxdoo releases are now organized into three categories, or packages as SourceForge calls them, qooxdoo-current, qooxdoo-legacy and qooxdoo-test.

qooxdoo-test contains all pre-releases like betas or release candidates. qooxdoo-legacy holds all stable releases up to, but excluding, the current line of qooxdoo releases; this currently includes all releases up to 0.7.4. qooxdoo-current holds the 0.8 release as the most recent and stable version.

The aim is to make the latest qooxdoo version more prominent, even though a legacy release might be more recent (like it was the case with 0.7.4). Unfortunately, SourceForge always highlights the most recent release, so don't be confused if you are offered a 0.7.4 download when you enter qooxdoo' SourceForge project page. qooxdoo 0.8 is still the most advanced release.

Generator

More URI Handling

After the re-work on URI handling recently, those changes are slowly showing up in the framework apps themselves. Since framework apps usually don't need dedicated "uri" settings in their library references, they have been removed. This includes the popular setting fed by the QOOXDOO_URI macro, which has been removed along the way (well, if you don't have a specific setting, you don't need a macro to fill it, right?!). If you need to override this for libraries that come in by using external configs, you can just do so by specifying the particular library in your local config and add a "uri" parameter to it. See here for more details (look for the section Overriding 'uri' settings of a library).

As a consequence, the also popular APPLICATION_URI macro is gone. With the current implementation of giving precedence to library 'uri' settings over compile-* settings, we couldn't keep the 'uri' slot in libraries just to provide a place to slip the macro in. As said above, the new handling is to add a library key for the application in the local config, where you can specify the application's URI (bug#1646).

QOOXDOO_PATH Macro

The QOOXDOO_PATH macro in config files is now used more consistently, e.g. when including other config files from the qooxdoo installation. Its value is now therefore the main qooxdoo (SDK) install directory, not the framework subdirectory. Please adjust your configs accordingly. The skeleton's generate.py will also look into the config.json to fetch the value of QOOXDOO_PATH for its own workings, so you can switch environments with a single change (but beware that the scanning is naive and e.g. doesn't account for comments; it just takes the first occurrence of the macro; bug#1456).

"themes" Config Key

The "themes" config key has been renamed to "asset-let", to better reflect its purpose. Though it is mainly used to inject theme-relevant information into the #asset hints, it's a general-purpose macro facility for those hints. The new name reflects that and avoids unnecessary confusion.

Solved issues

Some of the fixes and improvements include:

• Key press events are now working again properly when qx.event.Command is used. See Bug #1700 for more details
• Many issues concerning qooxdoo WYSIWYG editor HtmlArea were solved. A more detailed blog post about the recent improvements and the state of the widget is planned.

Blogosphere

Recently one could notice quite some increased activity in the "blogosphere" regarding qooxdoo. Frequently existing as well as new users mention qooxdoo as their framework of choice, or at least as one that is part of their current framework evaluations. That is great, more developers seem to appreciate the powerful, if not unique, features of qooxdoo for creating rich internet applications.

But there are still too many people that don't know (enough) about qooxdoo, and it would be great if the existing community could help in letting those potential users know. So, if you happen to run your own blog, or you're part of some technically related community, or you notice a discussion somewhere on the net that could really benefit from bringing up qooxdoo, please take the chance to talk about it. Of course, try to add real value to a discussion, and not to bother people that aren't interested. Keep passing the open windows...

A professional and independent review of qooxdoo has been the recent article at Webreference about Popular JavaScript Framework Libraries. Covering a number of frameworks in this series of articles, Rob Gravelle does a great and accurate job as an author in highlighting many qooxdoo specific strengths.

In his private blog, Kenny Tilton is less neutral about other frameworks, when talking about his experience as a new user of qooxdoo. While he has a strong Lisp background, The Road to qooxdoo might also be an interesting read for any developer independent of his/her programming CV.

Release 0.8.1

Ok, that's it for reporting some of the things that happened last week. Stay tuned for the release of qooxdoo 0.8.1. Oh wait, who's knocking?

During my recent studies for the new data binding layer I implemented an array wrapper in qooxdoo. The best way for a reduced set of API changes compared to the native array was to map the native JavaScript array to a qooxdoo array and add some custom events to the qooxdoo implementation. Doing that, I discovered some strange behavior of the browsers' implementation of the sort() method for a native JavaScript array.

The following code demonstrates this:

 
<html>
<head>
	<script type="text/javascript">
 
function load() {
  var array = [1, 2, 3];
  array.sort(function(a, b) {
    document.getElementById("out").innerHTML +="a: " + a + ", b: " + b + "<br/>";
    return a > b;
  });
}
	</script>
</head>
<body onload="load()">
<div id="out"/>
</body>
</html>
 

The important part is the sort() method, which is given a function to sort the JavaScript Array. This function logs the given parameters to the innerHTML of an DIV element. The results for the array [1, 2, 3] were more different between browsers than I thought:

Output: FF3
a: 1, b: 2
a: 2, b: 3

Output: Safari 3.2
a: 1, b: 2
a: 2, b: 3

Output: Opera 9.6
a: 2, b: 1
a: 3, b: 1
a: 3, b: 2

Output: IE 7
a: 2, b: 3
a: 3, b: 1
a: 2, b: 3

As you can see, there is no difference between Firefox 3 and Safari 3 (and never were during all my tests), but there are some remarkable differences to Opera and Internet Explorer. By returning always '-1' as a result of the sort function, I created the best case for those two sort algorithms, while creating rather a worst case for the others. Another interesting part is, that the order of the parameters is different among algorithms.

As a consequence you might not have a roughly equivalent execution time in all browsers, even with the same sort function And you can not rely on the order of the parameters, even if the array is already sorted before the actual call of the sort function.

Try out the corresponding test application yourself.

Most activities during the week were related to preparing for a

qooxdoo 0.7.4 release

This release for the legacy line of qooxdoo was made available last Friday. See the corresponding blog post for more detailed information.

Generator

The tooling of qooxdoo 0.8 is constantly being improved, and here are some of the latest changes:

• Including all classes in source versions
  There has been a bit of pondering about the question whether the source version of an app should include all classes of all involved libraries. This was the default in the 0.7.x line of qooxdoo, and could be disabled through a build variable. The full set of class files allows you to add new classes to your code without re-generating the application; you see the effect just by reloading the app in the browser. On the other hand, running the generator on the app or loading it in the browser might take substantially more time with the full class list. So it's an ease-of-development vs. speed tradeoff. The outcome is that we will leave the standard source job with only the necessary classes, but will add a source-full job to generate a version that has the full set of classes referenced. Then you can make your own choice which flavor of the source build suits you best.
• The speed of the resource compilation process has been optimized.
• The skeleton template configs (at least of the gui and migration template) received 'export' job filters, to unclutter the job listing you get with the 'generate.py x' shell command. Now, only the standard application jobs (source, build, api, test, ...) are exposed. If you need access to the lower-level jobs, just comment out the export key.

That's it for now. Next weeks status update will sum up some of the progress that's being made in the framework for a 0.8.2 0.8.1 release, scheduled before Xmas. C U.

Name spaces, that is, little buckets where you can keep names of variables without littering the enclosing environment, are not so straight-forward in Python as they are e.g. in JavaScript. Basically, there are only these language units which provide a name space:

• a module (ie. a file containing Python code)
• a class
• a function
• a dictionary (well, sort of)

A module is the normal name space, usually the one you want to embed further name spaces into. Functions work, but are a bit tedious. E.g. you can attach function variables as function attributes, like so:

def foo():
    a = 3
    def bar():
          print "bar waz ere"
    f.a = a
    f.bar = bar

foo()
f.a        # yields 3
f.bar()  # prints "bar waz ere"

You have to attach the interesting variables to the function object explicitly, and you have to invoke the function once, in order to make them active. So there's a bit of overhead here.

Classes are the classical name space in Python, and probably the best way to create a name space e.g. on the file level. But what if you need a name space in a function? This is especially interesting if you want to modify variables in nested functions that are defined on the parent function's level, since this is only possible with class or dict members. How to get those quickly? Classes and dicts have the overhead that you have to create each nested name space explicitly. With dicts there is the syntactic overhead when referencing elements, the brackets and quotes, like with "f['bar']['baz']".

A very convenient way of getting at the issue is with a simple class that overrides the __getattr__ method.

class NameSpace(object):
    def __getattr__(self,name):
        p = NameSpace()
        self.__dict__[name] = p
        return p

The __getattr__ method, if present in a class, is called when member lookup fails. By overriding this method you can create nested objects on the fly. So with the above class you can now write:

n = NameSpace()
n.a = 3                           # this would work with every self-defined class
n.opts.basic.log.level = 3  # but this
n.opts.advanced.dithering.shaded = True  # and this usually wouldn't

This saves you from the tedious task of creating intermediate layers in objects or dicts. You can just dash ahead and create nested name spaces to your heart's content .

Yes, a new release is out the door. Please note, this time it's for the legacy line 0.7.x. The latest and greatest qooxdoo version is still 0.8.

qooxdoo 0.7.4 is a genuine maintenance/bugfixing release. Many issues have been resolved, also due to some great feedback from and collaboration with the community. There are no known API changes, so it should be a fine replacement for a 0.7.3 version. Of course, some of the behavior may have changed a bit compared to the previous version, but only to make things more consistent and to behave as expected.

For some more detailed info about fixes and changes, please see the release notes. Of course, there are the usual demos, but keep in mind that it's a legacy version. Any new users of qooxdoo should go for 0.8.

Thanks to all the fellow developers, contributors and users of qooxdoo for their great support and collaboration!

Some time ago I've blogged about the "fun" of implementing a consistent cross-browser key event layer for qooxdoo. Today I found another nice item for my collection of key event bugs. Erich Konicek from the qooxdoo community reported a bug, where special keypress events did not fire. If the user presses any of the up, down, page up or page down keys inside of a text field, qooxdoo will not receive a kepress event in Firefox. Related keys like the left or right arrow keys do work as expected.

Firefox will create a keypress event for these keys but for some unknown reason the event does not bubble up the document tree. This is a problem for qooxdoo because we use a single keypress listener per application, which is attached to the document element. If some press events do not bubble, we are not able to handle them.

I have a very simple test case, which shows the problem. If you press the "up" key, "keypress" is fired on the text field but not on the body. I've filed it as a bug in the Firefox Bugzilla. I'm hoping this gets fixed soon, even though one other Firefox bug I'm following is UNVERIFIED for almost 4 months now.