The week in qooxdoo (2008-07-25)

Time for another weekly status report:

qooxdoo 0.8 development


Menu implementation is complete. The algorithms were greatly improved to have a very well working menu placement. The timeout infrastructure was improved as well. It now uses only two timers for all menu instances instead of two for each menu. Key handling and mouse handling features are also leaps ahead of the old implementation. The code got a lot leaner and cleaner.

The implements the IFormElement interface. The implements the IRadioItem interface. This means that both are now compatible to all the other form elements in qooxdoo and can be easily connected to them.

A MenuButton class was added to qx.ui.form to make it easy to add menus to normal standalone form buttons without requiring a toolbar.


A SplitButton was implemented to be used either in toolbars or standalone in simple forms. A SplitButton combines a normal button with a menu button in one visual component. This type of widgets is typically seen for history buttons in browsers, where a down arrow opens a popup menu that lists the previously visited sites. To be consistent, the SplitButton also implements the IFormElement interface.

Generic alignment

Menus, like the popups and tooltips, make use of the new alignment API to align widgets relative to each, to mouse event coordinates or to DOM elements. This generic API also supports a smart fallback handling to find the best available solution if the initial side has not got enough space to show the entire menu. By using this new API we were able to replace all widget-specific code previously implemented for popups, tooltips, select boxes, etc. This reduced the overall code size and complexity significantly. API names may not been totally consistent just yet, we’ll iron that out shortly.

The alignment API may also be used in the low-level DOM layer, because the algorithms itself are implemented in a widget- and layout-agnostic qx.util.AlignUtil. It is independent from the high-level GUI toolkit. This means that this API may be used for websites and portals as well to facilitate the placement of widgets/elements relative to each other.

Active widgets

The qooxdoo Widget class now supports a new property keepActive, which prevents other widgets from getting activated (i.e. becoming responsive to key events), when the user clicks on them. This feature was required primarily for menus, but may be useful for other areas as well.

In the low-level layer major improvements for the fallback handling (when no active element was found) lead to more stability in the core framework.


This week porting the Table widget to 0.8 continued after it had been started end of last week. qooxdoo’s Table is one of the most comprehensive virtual grids out there. Nevertheless, migrating the widget is coming along nicely. Given the complexity and amount of code, one needs to repeatedly be reluctant to changing code while doing the fundamental migration itself. Progress looks good so far, so stay tuned for a reasonably stabilized Table next week.


A small issue was fixed for the last transition in the theme system were the old decorator was not correctly resolved.
The display of key shortcuts was corrected (adopted from Windows), it now uses a plus sign instead of a minus sign, e.g. “Ctrl+C”.
The ToolBar class now supports a method addSeparator for convenience.
Some issues of last week’s first basic implementation of a text selection API have been resolved.
Port of the widget-level drag and drop implementation just started.


The dependency to the external wget command, used for downloading contributions from the qooxdoo-contrib repository, has been resolved and the functionality is now available in a pure Python/PSL implementation. Unfortunately, due to the ViewVC service of Sourceforge being offline, the revision check had to be disabled. This means that if you include a contribution in your config, you will be downloading the same contrib over and over again with every new source or build generation. A work-around is to do an initial download with a ‘contrib://’ specification for the manifest key, and then change the key to point to the contrib in your local download cache, so the build process will use the local copy for further runs. We hope to re-enable the check soon, once SourceForge turns back on ViewVC service reliably.

As a consequence, the cache key has been modified to accommodate a new subkey, downloads, a path to the contribution downloads. The path key, denoting the path to the compile cache, has been renamed to compile accordingly, and some background information was added regarding this key. This is an incompatible change, so if you are working with the trunk version of the tool chain you have to adapt your config files!

Say Goodbye to Makefiles!

Probably the biggest perceivable change in the build environment is the demise of application-level Makefiles (well, most of them 😉 ). After thinning out the functionality provided by proper make targets over the last couple of weeks, now also the frontend is gone. That means, up to recently you could still invoke ‘make source’ in an application, and the call was immediately routed to a generator invocation. The following just hit the trunk as a replacement (we will further investigate if that is to be a long-term solution). Anyway, as of now you invoke a local ‘’ command instead, which is available in each application and the framework. It uses the same arguments as the generator (e.g. a ‘ source’ will generate the source version of the application). This applies to most applications in the trunk (exception is still the buildtool) including the Skeleton, so if you are used to fetching fresh skeletons from the trunk for your own development, this applies to you as well.

While some might find the current switch in trunk from ‘make’ to ‘’ tedious (well, which change isn’t?!), it also offers some immediate benefits, like you can easily add the ‘-v’ command line switch to your generator invocations to get debugging output. The story behind all of that is much more exciting: we are eventually getting rid of the ‘make’ build system all together, only requiring a standard Python installation. This is trivial on most OS, including Windows, were you eventually won’t even need a Cygwin installation any longer. We have a couple of ideas in the pipeline about how to make the interface to generator’s functionality easy and comfortable (borrowing ideas from buildtool). As you noticed there’s currently still much work being done in consolidating the low-level stuff. If you have any good suggestions in regard of a user-friendly build process, don’t hold back!

API Viewer

As one of the first applications qooxdoo’s API Viewer has been ported to 0.8. Johnny was up to the challenge, and besides the migration work he had also to become familiar with the code base. Nonetheless, it only took him a couple of days applying the changes described in the preliminary UI migration guide. The first change one notices is the modern appearance which came “for free” without changing a single line of code.
We will use the experience we got form the actual porting work and put together an application migration guide. Please note that the search function in the migrated API Viewer is still deactivated, since the ListView widget is deprecated and has been moved to qooxdoo-contrib. The Table widget will be used to display the search results, once its port has been finished. There are still some tweaks to make in the ported API Viewer, so it will be made available within the next few days. As a preview see the following screenshot (click!):


The place for adding, maintaining and collaborating on new features to qooxdoo saw a bit of spring-cleaning. It was made more consistent, but work on it continues, not only anticipating the adjustments for the 0.8 tooling, but also the reorganization of the existing qooxdoo RPC servers (Java, PHP, Perl, Python). They are to become regular contributions and will benefit from their new incarnation inside qooxdoo-contrib. Among other advantages, this allows for an individual release management without being dependent on the framework or one another.


Here comes the user-submitted “Real-life example of the Week”:

di-lemmata is a new project targeted at scholars of German literature. It combines linguistic concepts with modern programming techniques in order to enhance and support research in the field of literary studies. di-lemmata’s library application has been completely implemented in qooxdoo (0.7.3) and currently covers the lyrical works of 11 German speaking poets. Although the HTML pages of the project (i.e. the lyrical works themselves) are in German, of course, the GUI of the qooxdoo application is also available in English and Russian.


Next week will see an ongoing migration of applications to 0.8, e.g. demobrowser. Also porting the remaining widgets will continue (DateChooser, ColorSelector, …), and finally Table is to expected to stabilize as mentioned above. If progress permits and scope is appropriate, we plan on a first beta release end of next week. Stay tuned. 😉

Working with text selection

Last week I started to implement a (still basic) low-level Text Selection API which especially the high-level form widgets like TextField and TextArea can make use of.

As some of you might already know working with the native Selection and Range / TextRange objects is not one of the things a developer dreams of :-)

However, looking at the basic implementation one thing is quite amazing. Besides a little tweak for Opera three (Gecko, Safari and Opera) of the four major browsers share the same implementation.
Sure there will be some more differences to encounter when the development of this low-level layer moves on, but the start looks quite promising.

The week in qooxdoo (2008-07-18)

Greetings, qooxdooers, for another weekly wrap-up of the state of affairs in qooxdoo!


qooxdoo 0.8-alpha2 has been released just a week ago, thanks for all of your feedback. In the following days, major parts of the service platform (which also hosts qooxdoo) were moved both physically (from California to Illinois), as well as concerning software versions. We don’t know about you, but we felt major impacts of this migration, even after its official completion. Among other things the statistics features of Sourceforge will remain dormant until next month, so we don’t even have download figures for our latest release :-( .

But “after release is before release”, and we are already in full gear for qooxdoo 0.8-beta1, planning its scope and dispatching tasks. More details will be available soon at this space.

With keen interest we followed the recent release of Jython 2.5a1, a Python implementation in Java. As our tool chain is increasingly built on Python this is an interesting extension of available runtime environments for this code, and will most likely be warmly welcomed by developers at home in a pure Java environment. Initial tests with our generator done by Fabian were indeed promising, and we are looking forward to full support of our build tools by Jython.


The initial phase of basing our build chain on the new generator is drawing to an end. Nearly all targets available under the make-based system are now available with the new generator as well, the notable exceptions being ‘make test’ and ‘make buildtool’ which will be supplied later. Invocations of the ‘make’ command are now just a wafer-thin wrapper around the generator invocations which becomes apparent with some of our standard applications like the Feedreader. The Apiviewer is self-hosting again, i.e. you can generate the API documentation of the Apiviewer itself.

The documentation of generator configuration got much love from Thomas, and is now split into a main page, a page with in-depth articles about important concepts, and a reference listing of the configuration keys.

And finally, the Showcase application which showed its age has been removed, at least for the time being until it can be re-surrected with new shine and glory :-) .


A first basic implementation of a low level text selection API has been added. Currently this API allows to get the current selection as string and the current selection length as well as to set a selection on elements, text nodes and of course form elements (input and textarea). This API is available for all four major browsers Gecko, IE, Webkit and Opera.

Without further a-do, here is what else happened in the framework:

  • Most bugs reported for alpha2 were fixed – thanks to all the submitters.
    • A listener was added for draggesture events, to block gecko’s native drag and drop when resizing/dragging qooxdoo widgets around.
    • Window resizes now keep the correct cursor.
    • Support was added to minimize/maximize windows.
    • Flickering on initial click on a widget has been removed.
  • Support for line height property in fonts has been added.
  • More Window refactoring:
    • support for modal windows
    • extracted MMovable mixin
    • refactored MResizeable
    • added possibility to block interaction with the window contents; needed for advanced modality support
  • Port of Menu has been started
  • Port of the Table has been started
  • TabView has been polished
  • Work has been done on a modern TabView appearance


This week another qooxdoo real-life example surfaced. Zed Builds & Bugs Management is an application targeted at software development teams and combines the following components:

1. Automated Software Build Management
2. Task, Bug, Feature, Assignment, etc. Management
3. Discussion Forums for team dialogs
4. Wiki for documentation, team group design, document storage, personal pages, etc.
5. General server administration

The power of the application is in it’s pure web (qooxdoo!) interface, and the database which is shared among all facets of the application. Meaning your Wiki pages can query the task database, and your automated builds can update tasks as well.

If you created a qooxdoo application (or any software that leverages qooxdoo), please let people know about it. It is an excellent way to give back to this open source project. Just go to the real-life examples and add a section for your app, maybe including a screenshot, and add a link to an online demo if available. Thanks!

Essence vs. Ceremony

At the past Dynamic Languages 08 conference, Neil Ford of ThoughtWorks Inc. gave a keynote presentation entitled “Ceremony & Essence”, which took the case of programming languages to reflect on two fundamental approaches to any given problem: The “ceremonious” approach that builds libraries over libraries, creates patterns and protocols to eventually solve the initial problem with a huge flagship of infrastructure; and the other that creates infrastructure that remains light and compact and tries to get out of the way, allowing you to focus on the issue at hand.

Excessive ceremony is a dangerous trap, and not only for software itself but also for all the collateral efforts like documentation, configuration and release management. Here is a story of a personal encounter I had recently.

When I came across a broken link on the Python documentation web site, I would have ignored it since I knew how to get at the information anyway. But since Python is besides Javascript the other intrinsic language for qooxdoo, I thought “be a good citizen, save the world and report this broken link”. After some looking around I was directed to a feedback page that offered a couple of choices. One of them was that if I had spotted a concrete problem with the web site I should be so kind and open a bug for it in Python’s issue tracking system.

Now filing bugs is not the most pleasurable activity, especially if you need an account in the first place. But eventually I had filed my first Python documentation bug in two lines of text, which was really a no-brainer saying this is the page, this is the broken link on it, and here is it where it should actually point to. I felt like a good boy.

You might be surprise to hear about the feedback I got a few days later. The link had been fixed in the development system. Hmm. The (offline) development system was fixed but the (online) production system not?! I asked back and learned that the documentation was treated like released software. The current presence has been released (2 years ago) and will not be fixed but superseded by its successor which is expected to come out in a couple of months. So you accept your users running into a dead end for more than 2 years?! And the policies and procedures do not allow this trivial issue to be fixed?! – Thank you, ceremony!