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.

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

General

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 Sourceforge.net 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.

Applications

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 .

Framework

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

Community

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!

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!

Keeping up with our tradition of Friday's weekly reports, here is another, albeit very brief one.

This week was really a finish towards the 0.8-alpha2 release which we pushed out of the door this morning. Hope you're all hanging out with it . Most of the activities went straight to the release notes, so please check there for latest changes (although the release notes cover everything that happened since alpha1, so you might have to wade a bit through the details).

One other thing worth mentioning was a lively thread on the mailing list, about code assist files for IDEs (Eclipse, Aptana, ....) entitled "jseclipse". Discussion gravitated around generating code assist files from API documentation output from the generator. People interested in that should also look at the - unfortunatley somewhat outdated - wiki page about qooxdoo and Aptana. There were some interesting ideas floating around, so maybe we can build up on that. If there is code starting to accumulate around this topic we could set up a qooxdoo-contrib project.

That's it for this week - we're going to post-release-climactic chill . Be in touch next time.

Today another pre-release qooxdoo 0.8-alpha2 was made available. This milestone completes and stabilizes many of the exciting feature improvements and additions of 0.8. To get an idea of the sophisticated GUI toolkit, you may want to browse through the online demos.

Being an alpha release don't expect it to be complete in terms of features or API just yet. But if you read the comprehensive release notes, you'll see how this second release is an amazing improvement over alpha1. Even if it is not meant for production use, you should start to make yourself more familiar with the new stuff of the upcoming version 0.8.

Download this alpha release as a regular SDK or in form of other packages. Take the time to play with it and maybe try to prototype some new apps. It would be great to get your feedback. If you find any issues, please don't hesitate to post bug reports.

Last week we attended the Java Forum in Stuttgart/Germany, which is organized by the local Java User Group Stuttgart (JUGS). Even for us rather JavaScript-oriented guys this was really a good conference. With more than 1000 attendees it was larger than expected. Just the conference track itself with 42 presentations was worth the car ride on the painfully congested A8 highway to Stuttgart. Initially we just expected to attend some of the presentations, but as 1&1 also had a booth at the exhibition floor, we were asked to support our colleagues during session breaks. At least we had made sure they brought some of the qooxdoo give-aways (flyer, ball pens, highlighters and, of course, the little candy boxes).

Once we were putting the give-aways onto the table people started asking what this qooxdoo thingy is all about. Some of them had already heard of the project and many of the Java crowd associated it right away with Eclipse RAP . Luckily Andreas brought his laptop with him, so we were able to do live demonstrations. The feedback was very positive. Most of the visitors were professional software developers and almost everyone had to deal with some kind of web application anyway. Many feel the pressure from their customers, who no longer want to deal with those old-fashioned,  form-based web applications. There certainly is a huge demand for rich internet applications (RIA), even among rather conservative, business-oriented customers.

One talk we simply could not miss was the talk by Stefan Röck and Frank Appel about their project experience with Eclipse RAP. Frank Appel is the technical lead of the RAP team at Innoopract and Stefan is a software developer at CAS Software AG, who works on a brand new RAP-based CRM application. They gave a live demo of teamCRM and explained how they were able to build it using Eclipse RAP. teamCRM is probably the most advanced RAP application to date and people were really impressed.

We enjoyed the conference. Thanks to the organizers and all the people that we had really interesting discussions with. Wanna join 1&1? Anyway, we'll definitely come back next year.

I always wanted to play with the browser's canvas element but never really found the right toy project. Then I read Ariya Hidayat's blog post "Let there be color". He has implemented the HSL color pie using Qt's 2D drawing canvas. How hard would it be to put something like this into the browser? I decided to try the port of his code to JavaScript and render the pie using only canvas. If this worked out maybe I could embed it into nice little qooxdoo windows.

Once I figured out how to realize "putPixel" and "getPixel" functions in canvas the port was merely a copy and paste with some minor changes. Right now I use the canvas methods "getImageData" and "putImageData" to obtain and render a pixel buffer. Unfortunately these methods are only available in Firefox. I'm still looking for an alternative for Opera and Safari. The last missing part was the conversion from HSV to RGB but luckily I could drop in a modified version of qooxdoo's hsbToRgb method.

Now the port could start. What really intrigued me was that the main algorithm was nearly the same as the C++ code. Just take this code fragment from the original code:

for (int i = 0; i < radius; i++) {
  qreal hue = 1 - init;
  qreal sat = 1 - qreal(i) / radius;
  for (int d = 0; d < depth; d++) {
    qreal value = 1 - qreal(d) / depth;
    QColor color = QColor::fromHsvF(hue, sat, value);
    img-&gt;setPixel(width / 2 - radius + i + 1, center + d, color.rgb());
  }
}

and compare it to the ported JavaScript:

for (var i = 0; i < radius; i++) {
  var hue = 1 - init;
  var sat = 1 - i / radius;
  for (var d = 0; d < depth; d++) {
    var value = 1 - d / depth;
    var color = hsbToRgb(hue, sat, value);
    setPixel(img, width / 2 - radius + i + 1, center + d, color);
  }
}

Basically only the variable declaration is different. The same is true for almost all of the relevant code. My first version was an all in one HTML file with the JavaScript code embedded. I used no framework, just plain JavaScript.

Of course I wanted to use some qooxdoo, so the next iteration was to put this into a qooxdoo application. Up to now qooxdoo had no support for embedding canvas elements into a qooxdoo widget. I used much of the new 0.8 widget infrastructure to create a canvas embedding widget. With this widget I could take the code from my first version and embed it into a qooxdoo window. You can see this application life or download the sources. This code is based on the latest qooxdoo 0.8 trunk.

Have fun!

German Java Forum 2008

Andreas and Fabian joined the Java Forum 2008 (german web site) on Thursday in Stuttgart, Germany. There will be a dedicated post about this one, but among various interesting presentations there seemed to have been a surprising amount of interest in qooxdoo. Stay tuned...

Generator

The Generator basically saw the addition of some missing targets from the Makefile world, like 'clean', 'pretty' or 'lint'. That means the new Generator is nearing feature completeness as far as the driving of project-level targets/jobs is concerned. Also, the module structure has been improved.

Dynamic switching of locales and themes

A major issue of concern during the last few weeks was the cost and benefit of supporting locale and theme switching at runtime in the next version of our framework. To that end, Fabian started a general poll on the mailing list to find out how important these features were for our users. In his summary of the ensuing discussion, he expressed surprise about the amount of support in favour of locale switching. Fortunately, there was also a solution found that promises both the availability of locale runtime switching but at a reasonable cost on the implementation side.

The envisioned solution will implement locales as being static during runtime as the default, which will result in some memory/performance gains. But it will also offer a dedicated setting to turn dynamic switching on for an application, and then the runtime costs will be about the same as they are in the current version. So this feature will continue to be available for those who wish to use it. On the implementation side, the relevant point was to bypass the (costly) LocalizedString class and use built-in Javascript strings to handle necessary meta information.

Runtime switching for themes is still an open topic. There were fewer postings speaking in favour of it, but still some interesting technical suggestions how to continue it in a more feasible way. This will be sorted out in the near future.

Framework

Here are a few more ramblings about recent changes in the qooxdoo framework.

• The 'Modern' theme is making advances, and we expect to have a working version during this week.
• A major refactoring of the focus system now leads to unique support for complex cascaded widgets like the Spinner or the ComboBox. The outer widgets always receives the focus event etc., and still the caret is visible when jumping from field to field when using the keyboard. Widgets also now have the possibility to differentiate between tab focus and normal focus.
• All qooxdoo widgets use the new subcontrol support now. This means that features built on this like the new appearance theme handling are now much more widely used. More details on this feature and the changes to the appearance themes needed will follow in the coming weeks.
• Support for aliases has been added to reduce the size of themes. Aliases also make the new sub control support a lot more usable. It greatly reduces the overhead introduced with the sub control handling in the last week.
• State inheritance to sub controls is now supported. This means that every child control like e.g. the up-button of the Spinner can be informed about specific state changes, such as "focused". This is especially useful or even required for better looking themes. You can see the new feature live in the improved Spinner and ComboBox widgets.
• Greatly improved performance of the appearance system through an improved caching algorithm. Instead of dynamically sorting an array and concat'ing it to a unique identifier the new implementation is based on a simple arithmetic loop. There were some other improvements as well. Especially the new alias support, as mentioned above, results into a few performance improvements as well.

Some minor improvements include:

• Fixed PageUp/PageDown support in all ScrollArea based widgets like the List.
• More API docs were fixed or extended. Especially in qx.html.* and qx.ui.core.*
• The TabView widget was improved to make better use of the SlideBar widget.
• The GroupBox widget was fixed and now correctly handles all legend types e.g. Atom, RadioButton or CheckBox.
• Added some new methods to the lower level classes in qx.html.*, to give a better API for focus related features of the widget system.
• Fixed appearance queueing for dynamic widgets like the Atom. Sometimes the states were not correctly displayed after initial rendering.
• Improved Splitter demo. The code was structured into separate methods.

That's it from this week's qooxdoo - enjoy your time!