One of the major problem of JavaScript frameworks is that you, as the user of such a framework, cannot easily control one of the initial settings. For example the framework may have defaults which only can be changed after the framework is loaded, but not before. Most of the time this restriction is not problematic. Many stuff is just then interesting when the application main gets processed. But there are exceptions like things which must be configured at loadtime and not after that.

This is where qooxdoo’s new sophisticated settings system comes in. And the best is that this feature is directly built into the core of qooxdoo. This means that many intial settings are easily controlable using a simple hash map structure or using simple generator flags.

For example you can control the following things in qooxdoo:

• All type of themes (colors, icons, widgets, appearance)
• Default log level and appender
• Resource-URLs of standard qooxdoo icons and widgets images
• Timeout of the image preloader
• The init component (graphical or non-graphical)
• Different debugging options for json, remote io, etc.

This list shows you some of your possibilities.

Generally settings are not meant to replace the properties which exist in qooxdoo. Settings are unchangeable. There is only a default value, defined by the class which declares the setting, and a optional user value which overrides this default value. The only possiblity to change this user value is to use the generator option or to define a global map qxsettings before including the qooxdoo JavaScript file(s). It is not possible to modify the value later.

As a class developer it is quite important to not use settings for everything. The intention is to reduce the number of settings to a minimum. They are only meant to control loadtime relevant stuff. Other things should be resolved with other available technologies like properties. Properties have a much greater set of features and possibilities.

New settings can be defined in this way:

qx.core.Setting.define("ns.key", "value");

In comparison to Variants there is no array of available values. Settings are not limited in this way. You can even store any JS-Type to a setting. But normally it is better to just use primitive types like Boolean, String and Number values.

The new class definition style allows you to integrate the settings in your class definition:

qx.Class.define(
{
  [...]
 
  settings : {
    "ns.key" : value
  }
});

The key should always contain a namespace. This protects the application developer from creating conflicting settings with the framework and maybe other qooxdoo-based libraries. The namespace could be something short. All qooxdoo settings use “qx”, like the toplevel namespace. If you have a “myapp.Application” you may want to prefix all your settings with “myapp” (but deeper nested namespaces are also possible).

Even if settings (and variants) are defined in the class where they are used, they are stored in a more “global” manner and may be accessed from everywhere.

You can select a new value for a settings using the generator or a global map defined before loading qooxdoo.

generator.py [...] --use-settings ns.key:value [...]

window.qxsettings = {
  "ns.key" : value
  [...]
}

For example you can select the initial icon theme to use using:

window.qxsettings = {
  "qx.iconTheme" : "qx.theme.icon.CrystalClear"
}