Here's another weekly report, which collects input from the various core developers (thanks, guys!) and tries to massage it into a (mostly) coherent and appealing blog post ...

Form API

We introduced a new property on some form widgets called placeholder. Perhaps you already know what to do with it? If, for example, a TextField is empty, the placeholder will be displayed in a light grey font to give hints on what to enter. Five widgets did get this placeholder feature:

To see the placeholder feature in action, take a look at the form demo in the online demobrowser.

Another new feature in the input fields is the possibility to filter the input. The following code snippet shows how it could be used.

var textfield = new qx.ui.form.TextField();
textfield.setFilter(/[0-9]/);

This feature in the input fields allowed us to improve the spinner and the ColorSelector.

ComboBox

A ComboBox is like a TextField with a drop down of predefined values. A ComboBox is often used to improve usability. For instance, an app developer could add the least recently used (LRU) values to the drop down. This is quite convenient for the user when required to enter a value.

Of course, there are other use cases for the ComboBox. The main difference to the SelectBox is that the user can enter individual values or choose from the pre-defined ones. A question remains: should the ComboBox have a text value set initially?

This question can really only answer the app developer depending on his/her specific use case. At least the ComboBox shouldn't set any text value per default. But this was the behavior implemented so far, the ComboBox used the value of the first element of the drop down to initialize the text field. Also by looking at other toolkits and OS interfaces we decided to account for that common behavior: the ComboBox initializes with an empty value for the TextField (of course, if no value was set programmatically). That's the way it's implemented in the current SVN trunk. So you might consider adjusting your code when working with the trunk.

An XmlHttpRequest oddity

Two failing qx.io.remote unit tests exposed what looks like a bug in Safari 3 and Firefox 1.5: If a qooxdoo application has a qx.ui.embed.Iframe with another qooxdoo app running inside, some AJAX requests sent by the inner app using relative URI paths will lead to 404s: The XmlHttpRequest implementation in both browsers seems to treat URIs as if it was running in the topmost browser frame, so that, in a case like the qooxdoo Test Runner where the embedded application is located in a subdirectory of the outer application, that directory will be omitted from the GET requests sent to the server.

Granted, this use case is fairly specific and both browsers are obsolete, but we'd still like to hear from anyone out there who might have run into this issue before.

RPC Perl

Tobias Oetiker has put forth the first release 0.1 of the RpcPerl contribution, a server-side implementation of the qooxdoo RPC in Perl, making this the fourth contribution kit (i.e. archive) online at sourceforge.net. The new release is a brushed-up, but fully backwards compatible version of the so far unreleased software. Taking this opportunity, a new piece of documentation has been added that details the process of creating a SourceForge release from a contribution.

Online Demos

All demos at demo.qooxdoo.org are back to a standard-port, non-redirect implementation, so all issues with blocking firewalls and lost fragment identifiers should be gone :-) .

Bugfixes

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

Community Award

As you should already know, qooxdoo has been chosen as a finalist in the annual SourceForge.net Community Choice Awards. It would really be great if you supported the project byvoting for qooxdoo in the category Best Visual Design. Thanks!

Have a nice weekend.