The week in qooxdoo (2011-03-25)

Another weekly status update for you.


This week yet another step was done towards the upcoming qooxdoo 1.4 release as we completed the experimental implementation of the new VirtualTree. Give it a try:


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

Ramp down

As we are quickly approaching the upcoming releases, due in less than 2 weeks, polishing and testing the code base is our top priority. If you still notice any major issue when working with current SVN trunk (or branch_1_3_x), don’t hesitate to file a bug report (but as always, please do a search first to not report known issues again). Other than that, help out your fellow qooxdoo users on the mailing list while we are busy with release activities, thanks.

Have a nice weekend.

Variants, Settings and the Lot

Since long qooxdoo supported the idea of a set of global values that can be queried from different parts of an application. Among other things, this was used in the framework to add debug code in the form of additional tests and logging, to provide browser-specific implementations of certain methods, asf. You can think of this set as a global key:value store for the application. Values were write-once, read-many. There were keys that came pre-defined with qooxdoo, and others that could be defined by the application itself. Values for those keys could only be provided at application startup, and not changed later.

A Re-Cap

So far, we had two separate buckets for global values: One with just plain values, called Settings. Settings were used to simply feed key:value pairs into an application.

The other were Variants. From the application coding side, they were like settings. During an application run, each had a single, well-defined value, which the programmer could query through various functions. Like with settings you could feed a value for a variant key through the Json config, the index.html or an URL parameter to the application. Unlike settings, though, variants had special consequences on the tooling side of qooxdoo:

  1. You could specify more than one value in the Json config; this would result in multiple application files being generated for the build version of the app, one for each value. (This was particular popular for creating browser-specific builds, e.g. one for mshtml, one for gecko, one for webkit asf.). If multiple variants had more than one value, the generator would produce an application for each combination of the possible values of those variant keys.
  2. During the creation of a single of those potentially many applications, the generator would remove code that did not apply to the variant value currently in effect. This meant a lot of code, e.g. for debug handling, could be removed for the optimized build.

The new word – Environment

With the upcoming 1.4 release of qooxdoo we will have a concept that embraces setting, variants, and a third source of global values  for an application: values typically detected at run time, like the current JS engine, the browser version, or supported features like  HTML5 web workers or data: URLs. Those had previously a completely different API in the* name space, with sometimes inhomogeneous ways to get at various bits of information.

All those values the application can draw from are now put together in something we called the environment of the application, with a single API. (In programming language semantics, the “environment” is often the term to refer to the set of bindings that are in effect when a certain piece of code is executed). The new API is qx.core.Environment, and its main methods to query key values are and qx.core.Environment.get(). is a straight port of It takes a key string and a map, and returns the map value which key matches the current value of the key string passed as the first parameter.

qx.core.Environment.get() is a simple getter, which takes the key string as a parameter and returns the current value, if any. This can be used, among other things, in condition expression where you previously might have used qx.core.Variant.isSet(). And like with qx.core.Variant.isSet(), those calls will be optimized if the call to qx.core.Environment.get() is the only expression in the condition, or is part of a simple comparison (==, ===, !=, !==) with a literal value. So you get basically the same code optimizations as with qx.core.Variant.isSet().

Settings and variants are continued to be supported in the upcoming release, so there is no need to rush. But you will get appropriate deprecation warnings when using the old qx.core.Settings and qx.core.Variant APIs.

The week in qooxdoo (2011-03-18)

Another weekly status update for you:

VirtualSelectBox and VirtualComboBox

This week another step towards the upcoming release qooxdoo 1.4 was done by completing the implementation of the new VirtualSelectBox and VirtualComboBox. Give it a try:

Mouse Wheel Scrolling

You might remember a blog post we wrote some time ago about the mouse wheel and how hard it is to get the scrolling speed done right across all browsers / operating systems / hardware devices. We used to have a specific list of browser checks to normalize the speed of scrolling. As you can imagine, that’s quite a maintenance nightmare, particularly as some browsers like Webkit/Safari/Chrome seem to have changed values significantly in the past. This is why we came up with a dynamic solution which is now enabled by default (but can be disabled). Just give it a try by using the mousewheel in scrollable widgets (e.g. in the devel snapshots due each Friday), and send us feedback if it works out fine for you, or what downsides of the new behavior you notice.

Dependency Analysis

The dependency analysis of the generator, particularly for load-time dependencies, has been extended. More dependencies are now detected, so that load ordering is more dependable. This slightly increases the analysis time in some cases. To account for these activities in the generator output, a “_” (underscore) now indicates recursive analysis of a method, which has to be done in specific calling contexts when the method call introduces further load-time dependencies.


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

That’s it for now. We’re quickly approaching the upcoming qooxdoo 1.4 release, which is due in three weeks. If you are aware of any unknown, severe issues, please file bug reports, thanks.

The week in qooxdoo (2011-03-11)

Welcome to another weekly status update.

Table Styling

Ever wondered how to style the table widget and what theming capabilities this widget has? If so then grab yourself a coffee and read the brand-new documentation about this topic in the manual.

Feature Detection

We are currently working on qooxdoo’s detection system. We already moved some of the old detections into our new system and added deprecation warnings for the old stuff. As soon as we have finalized it, we’ll let you know about the new features and how to benefit from them.

Support for data: URLs

As already introduced last week, we’re adding support for data: URLs to qooxdoo. Last week’s post was concerned with the creation of base64-based combined images. What has changed since then is that we tweaked the convention for the output file name ending to .b64.json. This way it is tagged as a regular JSON file (which is what it is), but has still a file extension that signifies base64-encoded combined images to the generator. We also removed the config key combine-images/images/../type as this information is fully covered by the naming convention. The section today is concerned with the integration of base64 combined images in a normal qooxdoo application.

When creating combined images for your application, you have to decide whether you want a particular image as part of a combined image, and if yes, in which kind of combined image. You have to make up your mind, as you cannot have an individual image in more than one combined image (This would defeat the automatic scanning and registering of embedded images within combined ones during generation).

Now if you have a couple of images put together in a combined image, this combined image will be scanned during generation (e.g. source or build) like any other image. If a contained image is used by the application the combined image is registered with the application, and the required image is marked as being contained in that combined image. During run time of the application, once the contained image is requested the combined image data will be used. That is, if the current browser supports the use of combined images. If not, the individual image will be used instead.

This all holds true for base64 combined images as well (not withstanding potential future adjustments to the detection of support for data: URLs in the current browser). E.g. a decorator using a specific image for decoration can use the base-64 representation of the image in place of the binary representation (like PNG). The main difference to binary combined images is the fact that for binary images the qooxdoo run time could rely on the browser to fetch the image file if it was used for the first time.

Base64 combined images on the other hand are textual files, the URLs of which cannot just be sensibly set as src or background-image attributes of a DOM element. Rather, the combined image has to be in place so that the base64 representation of an embedded image is accessible as soon as it is required by the application. Therefore, the base64 combined images are included with the resource information that is part of the loader and/or the packages of the application, and are loaded directly with those .js files.

So, for you as an application developer all you have to do to make use of this feature is to create base64 combined images in the source/resource/<namespace> path of your application (Have a look at the Feedreader source tree for an example which uses base64 combined images.). The generator and qooxdoo’s run time will take care of the rest.

Data binding & virtual list & tri-state checkboxes

This week we added another demo that showcases a couple of new features found in qooxdoo 1.3. Check it out to see the new virtual list as well as tri-state checkboxes in action. Be sure to take a look at the code and discover some data binding goodness.

New Feature: Filter for TreeVirtual Widget

We have added a new filter feature to the TreeVirtual widget in the qooxdoo trunk. By defining a filter method and setting it to the filter property of the SimpleTreeDataModel instance you can easily filter the data of the tree. You can find a demo for this feature in the devel demo browser.


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

Have a nice weekend, everyone!