Welcome to another round of tidbits from the qooxdoo world. WebTech09 has passed with some interesting presentations and meeting people (see more in this weekly), and now we're off to higher goals...

1.0 Beta

1.0 - we're getting there. As announced earlier we plan to ship a 1.0 beta of qooxdoo this coming week. It's a preview release, and everybody is invited to check it out and provide feedback. If you want to hold your breath, hold it around Wednesday .

Framework

Script Core

A small change can sometimes reveal bugs which are otherwise hard to find. Fabian changed the event which triggers the placement of a widget from resize to appear and suddenly disappear events from widgets were not fired any more. With this trail in mind we found out that unregistering an appear event will also unregister a disappear event and vice versa since only the target hash code was used to store the data. The fix was quick and easy: store the data using both the target hash code and the event type.

Data Binding

We added some work into the data binding this week. First, we added a data store for JSONP. On top of that, we added a YQL data store. The whole story can found in a separate blog post.

Performance

Performance is always an issue and with the 1.0 release on the horizon even more. We have identified a few bottle necks, which we could remove:

• setStyles vs. setStyles: All CSS styles in qooxdoo are applied by calling qx.bom.element.Style.setStyle(). This resulted in a lot of function calls and some duplicate operations. To solve this we have enhanced the setStyles() function which is able to set several styles at once. We basically have manually inlined the code of setStyle() and moved as much as possible out of the loop.
• Assertions: Even if assertions are mostly used in debug code, its's still important that the checks are as fast as possible. The assertion class has been reworked internally which gained some significant performance improvements.
• Dispose: While measuring performance we were surprised how expensive disposing of objects is. One small optimization was the deprecation of the _disposeFields method, which basically sets the given fields to null. Instead we set the fields directly to null which is equally concise but way faster.

History Manager

New browsers including IE8 Firefox 3.6 and newer WebKit based browsers support the hashchange event, which is fired whenever the fragment identifier (hash) of the URL changes. If available we now make use of this new feature to detect hash changes instead of the more expensive polling technique. In addition some issues in IE have been fixed as well.

Bugs

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

Applications

We introduced a new feature for the API Viewer this week: The throw information will be displayed for every method which can throw errors. qx.data.MBinding is a good example for this new feature.

Generator Configuration

The generator has a new command line option -m (or --macro for the long form) that  allows you to pass macros and their definition to the generator. Example:

generate.py -m foo:bar myjob

where foo is the macro name and bar the assigned value. You can specify multiple -m options. The effect is as if you wrote these definitions in the global let section of the configuration file  you use. Since these macros are evaluated very early, you can use them e.g. in top-level include keys if you want to parameterize an include file. In this vein, macros are now also supported in jobs' extend and run keys; this was formerly not supported, as these keys are among the earliest keys that are evaluated in a job (prior to full macro expansion), as they guide job construction.

That's it for this week, see you around next time.

As mentioned in the last weekly blog post, Fabian, Jonathan, Alex and I attended the JSConf in Berlin. As always after such good conferences, we came back with a lot of new ideas and a bunch of technologies to test.

One of the most impressive talks was held by Tom Hughes-Croucher on End to End Javascript. A big part of the presentation was an introduction to YQL, the Yahoo! Query Language. Yahoo! describes YQL as, "[...] an expressive SQL-like language that lets you query, filter, and join data across Web services". One important thing is that the data can be accessed via JSONP, which is easy to handle in JavaScript.

The plan was set up: build a qooxdoo data binding store for YQL. But the only available store was a JSON store, which fetches data via XHR and not via a script tag like it is used for JSONP. Former experiments with JSONP like the twitter demo and the flicker demo were good resources for getting a general JSONP store. On top of that new store, it was quite easy to create a store for YQL!

Here is an example reading a feed and showing the feed titles in a qooxdoo list.

var query = "select * from feed where url='http://feeds.feedburner.com/qooxdoo/news/content'";
 
var store = new qx.data.store.Yql(query);
var list = new qx.ui.form.List();
list.setWidth(250);
this.getRoot().add(list);
 
var controller = new qx.data.controller.List(null, list, "title");
store.bind("model.query.results.item", controller, "model");

Those few lines of code is all one needs to access YQL. And reading feeds is just the beginning. Take a look at the next code snippet, which is slightly different but shows all my recent tweets in the list.

var query = "select * from twitter.user.timeline where id = 'wittemann'";
 
var store = new qx.data.store.Yql(query);
var list = new qx.ui.form.List();
list.setWidth(250);
this.getRoot().add(list);
 
var controller = new qx.data.controller.List(null, list, "title");
store.bind("model.query.results.entry", controller, "model");

We just changed the query and a bit of the binding code and thats it: we have completely different content in our list. The last example shows the top music artists.

var query = "select name from music.artist.popular";
 
var store = new qx.data.store.Yql(query);
var list = new qx.ui.form.List();
list.setWidth(250);
this.getRoot().add(list);
 
var controller = new qx.data.controller.List(null, list, "name");
store.bind("model.query.results.Artist", controller, "model");

Again, we changed the query and some details on the bindings which configure the way the received data is accessed - and that's it!

If you want to give it a try, check out the code in the current qooxdoo trunk. But be sure to test your queries beforehand with the YQL console to get it working, or to get an overview of all available YQL tables.

Welcome to another round-up of events in and around qooxdoo!

JSConfEU - "That was Rock'n'Roll!"

With a lot of excitement Fabian, Johnny, Martin and Alex from the core team returned from this year's JSConf Europe, held in Berlin on the past weekend. If any of you followed the conference, either directly or remotely, you will have noticed the amount of positive reactions it received. It was probably the best Ajax/JavaScript related conference anyone of us had attended so far. With speakers like Dion Almaer, Douglas Crockford, John Resig or Thomas Fuchs the lineup was excellent. Being a rather small and focused conference really helped to improve the overall quality. Everyone there seemed to be working on some state-of-the-art JavaScript project. A particularly hot topic was server-side (or should I say: beyond-the-browser) Javascript, with presentations about CommonJS, Narwhal and node.JS. This really seems to get into shape.

On the second day Fabian gave a talk about the internals of the qooxdoo widget system. The talk was well received and it was fun to discuss the design decisions with authors of other JavaScript frameworks. All of us really enjoyed being there and we are already looking forward to the next JSConf.

Framework

Improvements on Blocker

We finished some improvements on our current implementation on Blocker. The methods for blocking and unblocking take care now of the number of method calls. This means if the block method is called twice, the blocker is removed when the unblock method is also called twice.  To force a removal two new methods are added, one for the blocker (forceUnblock) and one for the content blocker (forceUnblockContent), both methods remove the blocker directly.

Bugs

A lot of focus this past week went into fixing bugs and analysing performance. For a complete list of bugs fixed, use this bugzilla query.

Community

Two events hit qooxdoo-contrib this week. Burak Arslan issued a maintenance release of his JsQt. He writes:

"A maintenance release for JsQt is now up. I've also extracted properties
from Qt headers and put a compatibility table up. I hope it'll help
users better understand the capabilities of JsQt. I wonder how useful
they will be -- comments are welcome."

And sedulous Christian Boulanger has added the Dialog widget set. From the README:

"The Dialog project provides many often-used widgets required in user
interaction, such as alert, confirm, prompt, and others that simplify
the web developer's daily work."

It's at an early stage, and Christian welcomes  active collaboration.

That's it for this week - see you around next time!

Jython 2.5.1 came out a few weeks ago. Heavy work has been done on Jython in the last couple of months, also due to Frank Wierzbicki, who unfortunately left the Jython team at Sun recently.

We regularly look at the state of Jython and, also unfortunately, current qooxdoo (0.8.x) does not work with Jython 2.5.1. The implementation fails at the massive use of regular expressions in our parser. The error reported is a maximum recursion limit exeeded, which seemingly cannot be fixed from within the Python layer (e.g. with sys.setrecursionlimit). So Jython support for qooxdoo is still missing, and qooxdoo users looking at this platform still have to wait.

It has been a busy week while anticipating JSConf this weekend in Berlin. This is going to be a great event, and we're happy to be present there with four members of the qooxdoo core team at 1&1, including a qooxdoo-related talk. But now to some framework activities this week:

Part handling

A conceptual bug in the part handling of the generator was fixed that surfaced when using a lot of parts with a lot of packages. It occasionally hit when packages were merged by the generator, to reduce the number of files that constitute the application. It turned out that the merging process didn't heed the load-time dependencies of those classes it was moving around. Consequently, the solution was to track load-time dependencies between packages when doing the merging. A verifier was added to the generator that checks all parts are complete (wrt. class load-time dependencies) at the end of the merging process.

bash: Tab Completion

A small bash script was added (tool/bin/generator_compspec.bash) that provides tab completion for generator.py invocations. So if you're using bash, either on Linux/Unix variants, Mac OSX or Cygwin/Windows you can use this to type in a project folder ./generate.py <TAB><TAB> to get a list of available generator jobs, or the completion of a job name after a few characters. It's not sophisticated but might help some people working with the command line. Source the file in your .bashrc or .bash_profile to get it working on your shell.

Bugs

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

Google Closure

Most likely you've already heard the latest buzz: Google released a set of tools under the name "Closure". It basically consists of four parts: Library, Compiler, Inspector and Templates. To summarize in their own words it's "a broad, well-tested, modular, and cross-browser JavaScript library" that comes with "a JavaScript optimizer that compiles web apps down into compact, high-performance JavaScript code". Sounds familiar?

So lets welcome (yet) another JS library. Just the fact that Google is releasing such a library guarantees a lot of attention (see this section as an indication). Unlike the many widely-used low-level libraries (jQuery, Prototype, etc.), this one is a more comprehensive library with (at least) some tooling. We'll see how well it fares compared to existing - "modern" if you will - libraries/frameworks like Cappuccino, ExtJS, SproutCore, YUI and, of course, qooxdoo. From looking briefly at Google Closure, it somewhat "feels" like Dojo. While there are some sweet spots in Closure (e.g. some of the advanced optimization features of the compiler), frankly, I was rather disappointed. Given five years of qooxdoo exposure, I'm biased for sure, but unlike the unavoidable ecstatic commentors in the blogosphere, there doesn't seem to be all too much new, powerful or elegant stuff in Closure. What is your impression? Many of the modern JS frameworks mentioned above seem to have more individual - if not unique -highlights than Closure apparently does, not only when you look at typical GUI features. YMMV.

IMHO it should be an advantage to qooxdoo - as it is for all JavaScript-based application development - that Google is present now not only with end-user apps, developer-centric web services or its Java-based GWT, but also with a significant piece of open source JavaScript technology. Particularly the tooling aspect will gain much more focus among existing and potentially new web application developers. When compared to the other current JavaScript frameworks the integrated tool chain of qooxdoo is one of its strong points, besides a state-of-the-art GUI toolkit for creating rich internet applications. With JavaScript-based applications being (and even more so becoming) an extremely successful technology, qooxdoo is well-prepared and a mature solution for many challenges, don't you agree?

The road to qooxdoo 1.0

Talking of maturity this is to remind you of qooxdoo's ramp down towards the 1.0 release, which is still planned for the end of the year. During the last weeks, actually for several months now, a huge number of bugs have been resolved, enhancements implemented, larger topics and inconsistencies in the framework addressed. The testing infrastructure, that was established and improved in the course of the year, became a valuable tool as it helps ensuring a sufficiently high level of software quality. Among all the regular development activities, which we're able to pursue ourselves as full-time framework developers, the input and support of the community, contributors and committers naturally is of great importance. This is especially true for the challenges when approaching a 1.0 release.

We'd like to ask for your dedicated help and support during the next few weeks. For instance, if you encounter issues and inconsistencies that to your knowledge (please scan bugzilla first) aren't recorded or addressed already, please let us know. Pay special attention to all API related issues, as it gets naturally much harder to address those after a 1.0 release, which is supposed to gain much from API stability. Clearly, not all open issues can be resolved for qooxdoo 1.0, or any release after, but we're focused on addressing the most important and relevant defects as well as the most significant enhancements in a reasonable manner. Again, when reporting real defects, or requesting enhancements, please choose qooxdoo's regular bugtracking over the mailing list. This usually guarantees for the most effective and least redundant workflow without cluttering up the list.

All assignees of a bug are asked to review the issues soon, possibly working closely with the reporters in resolving them. If you happen to be the reporter of a defect or an enhancement, or otherwise interested in the issue being resolved, please feel free to approach the current assignee and offer your help. We regularly perform bug triage to never have a real defect unassigned. That doesn't mean that the assignee is going to work on such an issue promptly. If he/she does or plans to, the status is supposed to be switched from "new" or "reopened" to "assigned". See the bug handling documentation for more info. If you're in doubt, talk to each other.

In the next few days we'll also prepare for the 1.0 copy of the qooxdoo manual. Like the rest of the homepage it is just a wiki, so after a simple registration you can collaborate in improving the existing documentation. Everybody is encouraged to review the current articles, i.e. finding, reporting and preferably enhancing/fixing the docs. Language corrections by native English speakers are appreciated. Much of this also applies to the API reference, which is generated from the JSDocs of the qooxdoo code base. If you identify issues that should be addressed, at least report them, at best fix them yourself. It would make sense to carefully go through a current SVN checkout and review individual namespace packages. After you make the changes to your local copy, a patch file can easily be generated and attached to a corresponding bug report. We'd take care of applying your API corrections asap. Does anybody feel like participating and help coordinating efforts around the wiki and/or API docs?

When preparing the wiki for 1.0 in the next few days, we'd also like to correct a milestone misnaming: being in the ramp down for qooxdoo 1.0 for a while now we decided to rename the formerly planned (but then postponed) 0.9 release to a 1.0-beta pre-release. While there are certainly pros and cons of having another "formal" major release, this renaming matches best the status and progress of previous and current framework development. As with any release, beta or major, we'd appreciate you tried this code base at the time of availability, planned for end of November, in order to spot any open issues. This even more applies to SVN trunk, thus anyone of you that is able to run his/her qooxdoo apps against a recent trunk version, is encouraged to do so. Of course, we can't expect you to do this for your production code, i.e. in its deployed version, but often it might not be much effort for you to have a parallel version built and tested against qooxdoo trunk as well. Besides helping framework development, you'd also help yourself and your investment as being close to the qooxdoo trunk helps you to notice and react to any changes and regressions you'd not be comfortable with in a 1.0 or after.

It would be great if you kept an eye on the mailing list to help other community members with their problems and answer their questions. On a daily basis the members of the core team use to take care of supporting the mailing list. With more users helping out others (and some of you are really excellent in doing so!), the time saved could rather be invested in framework development and the upcoming releases.

Think about all ways you could (even more actively) support qooxdoo. Thanks!

Besides code a qooxdoo application maintains a fair amount of data that represents some sort of resources. This might be negligible for small to medium size applications, but becomes significant for large apps. The resources fall roughly into two categories,

1. Internationalization (I18N) Data
   like translated strings and locale information (such as currency, date and time formats, asf.)
2. File Resources
   mostly images like PNG and GIF graphics, but also static HTML and CSS files, sound and multimedia files, asf.

Many of these resources need an internal representation in the qooxdoo app. E.g. translated strings are stored as key:value pairs of maps, and images are stored with their size and location. All this data requires space that shows up in  sizes of application files, as they are transfered from server to browser.

Since version 0.8 qooxdoo stored nearly all of this information in the very first package of an application, the package containing the loader code which would bootstrap the application. For large applications, which lots of graphics and translated strings, this initial package would become very large. It would also defy the idea and benefits gained with application parts, as the data would cover all parts of the application, whether they were loaded during run time or not.

So we thought about splitting all these resource data out from the loader package and into the packages that actually need them. So the plan is to have translated strings in the package that actually uses them, register image data with them, and so forth. In a first step we now have forked out the static resources (category 2. above), so they would be filed with the requiring package and loaded together with it. This can decrease the size of the loader package dramatically, hence increase transfer speed and startup time of the application, and avoids loading of unnecessary data.

To increase the impact of this measure even more, the merging of packages within parts could use some enhancement too. Hence, a new experimental configuration feature was added to the generator. If you add no-merge-private-package : true to a part's config definition, the one package that is specific to this part (it's always exactly one) will be retained and will not merge however small it might be. This allows you to retain these specific packages, together with all the resources they might require.

This is particular interesting if you define parts that draw a lot of resources, but are rarely used or, even better, where you know only one of several parts will be loaded during run time (alternative parts). A concrete example for this scenario is an application that comes with multiple themes, only one of which will be loaded at run time. Each theme can maintain a large collection of resources besides the theme classes. Having those in separate parts will allow you to load just one of them with all its resource info at run time, without the others blowing up the sum total of loaded packages.

We'll see how this stream of thought will continue. For example, currently it is orthogonal to the splitting out of I18N data in locale-specific files, but I have the feeling that these concepts will nicely converge.

Welcome back to another roundup of qooxdoo happenings.

New generator job

We've added a new generator job named "info" to the GUI and Inline skeletons. Thus a generate.py info will display some environment information about the system, the Python installation and the qooxdoo framework version used to build the skeleton application. This information can be helpful for troubleshooting, especially for problems related to the build system, so you may want to include it when asking for assistance on the qooxdoo-devel mailing list.

TextField problem with IE8

An issue previously fixed resurfaced this week. A while ago a bug report was filed about "unreachable" TextFields in IE8 standard mode, something we thought was already fixed. But another report indicated that a certain widget combination indeed makes the TextField unreachable for mouse interactions. Such a combination is for example a TextField added to a ToolBar. A lengthy debugging session showed that the problem occurs if the parent widget has an image as decorator and the TextField is being laid out in front of it. In this case the image (decorator) got the user interaction and not the TextField.

We fixed the issue in the current qooxdoo trunk, but older versions are affected by this issue. It is possible to solve the issue with the following workaround for the TextField:

// IE8 in standard mode needs some extra love here to receive events.
if (qx.core.Variant.isSet("qx.client", "mshtml"))
{
  textfield.getContentElement().setStyle("backgroundImage",
    "url(" + qx.util.ResourceManager.toUri("qx/static/blank.gif") + ")"
  );
}

The workaround sets a transparent background image on the TextField to fix the issue.

Bug fixes

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

Simulator

The qooxdoo Selenium user extension's qxTableClick command can now locate table columns by using their internal ID as well as the column name that's displayed in the column header. See the Simulator wiki page for details.

Article

Recently a well-written article appeared in a German online magazine by qooxdoo user and web expert Timo Haberkern. A nice read. Well, maybe not if you need to insert a babelfish into your ear to instantaneously translate German into your own language ...

Real-life Examples

Another interesting example of a qooxdoo app was supplied by Mirko Thamm, who added some info about momentas, an events database with an appealing GUI using qooxdoo's optional RPC server for PHP.

RpcConsole

Talking of RPC, Christian Boulanger continued to extend and polish his RpcConsole contribution we blogged about last week. Straight from his today's post to the mailing list:

"I just committed a change to the RpcPhp server trunk that allows service introspection similar to the one found in XMLRPC: In contrast to the XMLRPC standard, the methods "listMethods", "methodSignature" and "methodHelp" are not methods of a virtual service "system", but are made available as parts of the service class itself. In PHP, this is achieved by extending the ServiceIntrospection class (which is automatically included by the server) or by implementing methods that forward to the API methods like so:

function method_methodSignature( $method ) {
   return new ServiceIntrospection( $this )->method_methodSignature( $method);
}

I would like to propose that the other backends implement this simple introspection as well. Of course, I am open to changes to the introspection API in order to achieve interoperability."

He'll surely appreciate your comments.




We are very excited about the upcoming JSConf, November 7-8, 2009 in Berlin. It is supposed to be The European JavaScript Conference of the year. Of course, qooxdoo will be present as well: not only will Fabian give a talk about some of the inner workings of qooxdoo's GUI toolkit. From the qooxdoo core team also Alex, Jonny and Martin will be at the conference. If you happen to also be at JSConf, they're happy to meet with you and chat. If you couldn't get a ticket, but are in Berlin at that time, maybe we could figure out some after-conference get-together. Let us know.

WebTech conference

Much of this also applies to WebTech, a newly introduced German web conference. It takes place on November 16-18, 2009 in Karlsruhe, were the core framework team at 1&1 is located. Carsten Lergenmüller, member of a qooxdoo application team, will talk about qooxdoo in action. If you'll be at the conference or just in town at that time, drop us a note so we could arrange for some decent qooxdoo beer.

Have a nice weekend and a successful working week!

This is another weekly activity report from the qooxdoo realm. Welcome!

Framework

Mouse Capturing

Last week we talked about how to track the mouse position while the cursor is outside of the browser's view port. Since then we have done some more work to bring our implementation of mouse capturing in line with the native Internet Explorer implementation:

• Bubbling: Captured mouse events are now bubbling.
• Container capture: By default events originating in the capture element are captured and dispatched on the capture element. The Microsoft API features an optional bContainerCapture parameter to turn this off. If the value of this argument is false events originating in a container are not captured by the container.

Unwanted Scrolling

When DOM elements are focused using the DOM focus() function, most browser will scroll the focused element into view. This cannot be easily prevented by static CSS and was an ongoing annoyance. Thanks to the work of Tim Buschtöns from the Eclipse RAP project we now have a way to prevent this kind of scrolling for selected widgets. We have added a disableScrolling method to qx.html.Element, which will block this kind of unwanted scrolling. By default it is active on the application's Root widget and the Desktop widget.

Bugs

Dynamic image switch

One of the latest addition to the trunk was the fix of bug#1909 which prevented application developers from changing the source of an image or the scaling dynamically during run time. This nasty bug was finally fixed and you're now able to use the Image widget without worrying when changing the image type or scaling.

Table

The Table widget can be scrolled using the mouse wheel. On some computers and a combination of FireFox3, scroll wheel speed and the Windows operating system the Table wouldn't scroll at all or jump directly to top or bottom. This week this issue was finally fixed.

API Viewer

The API Viewer got some love, too. We corrected the position of the icons indicating the type of methods and other attributes.

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

Generator

Stack Traces

Stack traces are an important aid in debugging, and it was a default behaviour of the generator to print a Python stack trace on exit through a fatal error. And it was nice to have this important information right at hand, when it happens. On the other hand, those stack traces confused people and, more importantly, obscured the error message that follows the stack trace, as they easily become large, unwieldy, and packed with internal details that are really only of significance for the developer. Therefore, we have made printing of stack traces into a command-line option of the generator. If you add -s (--stacktrace) to your generator runs, stack traces will be printed on fatal exits. But the default now is not to print them. The downside is: Whenever you encounter a problem with a premature exit of the tool chain, a common response might be in the future "Please re-run with the -s flag", so be prepared .

File Globs

There is a new section in the manual on using file globs, i.e. meta characters in file path expressions.

Community

HtmlArea: Undo / Redo support in IE

The support for Undo/Redo in IE is now again available in the latest trunk version of the HtmlArea. It was broken with the 0.8 update of HtmlArea due to the inability of IE to cope with DOM changes when the native Undo/Redo commands are used. Now the implementation does not use the native commands anymore and you can again use Undo/Redo capabilities in all browsers.

Simulator Updates

The qooxdoo Selenium user extension's hierarchical element locator qxh will now find child controls as well as child widgets added by the application developer. This is useful when simulating user interaction with a qooxdoo widget such as the ComboBox, which has two child controls, a text field and a button, in addition to any list items added by the developer. Previously, the qxh locator would find the list items but not the child controls, so clicking the button to open the menu or typing in the text field was impossible.
Here's an example of how to select the first entry from a ComboBox menu using the updated qxh locator:

qxselenium.qxClick("qxh=*/qx.ui.form.ComboBox/qx.ui.form.Button");
qxselenium.qxClick("qxh=*/qx.ui.form.ComboBox/child[0]");

Additionally, we've introduced a new locator with the prefix qxhv which works just like the qxh locator, but only considers visible widgets for each step.

RpcConsole Contrib

Christian Boulanger has come up with another nifty contribution: A qooxdoo interface to test RPC back-end services interactively. Here's a first screen shot:

See how you can enter a service, provide request parameters, send the RPC and inspect the response. Many developers working with RPC to communicate with the server will welcome this tool. In his announcement Christian writes that the application

"... allows you to test a backend rpc server. It is a very minimal client for the moment, but more functionality is to come - please let me know what you would like to see implemented. Of course, you can also look at the code and tell me what can be improved"

Especially people using back-ends other than the PHP RPC are invited to test and share their experience.

That's it for this week - see you around next time.

Welcome back to the roll-up of another exciting week in qooxdoo.

Scrolling Menus

For a long time qooxdoo's menu implementation was missing an important feature: If the screen was smaller than a menu required, the menu was cut off and some menu entries could not be selected. This is history. Large menus now use slide bars on-demand to scroll to initially hidden menu entries.

While implementing this feature the placement algorithm for menus was improved as well and a new widget was introduced: The little arrow buttons to scroll the menus react on mouse over. It is not necessary to click on them. This widget has been externalized into the HoverButton widget.

Mouse Capturing

This week we found the solution for really an annoying problem. The problem was that we didn't receive mouse events during drag operations in IE and Firefox if the cursor left the browser viewport. Thanks to qooxdoo user Petr Kobalíček, who pointed out that other frameworks can handle this situation, this issue could finally be resolved. The details are explained in an earlier blog post today.

Scrollbars

Soon after we had introduced the native scrollbars, we fixed a strange rendering bug only happening in Opera: the browser seems to forget the scroll bars's scroll position and needs some help to render it correctly.
The Scrollbar widget also got a new feature this week: If the scrollbar is too small to display the scrollbar knob at all or to use it reasonably well, the knob is now being hidden automatically.

Dependency Analysis

The recent changes to the dependency analysis (see last weeks blog post) led to Python hitting its internal recursion limit in huge projects, so we've increased this limit in the generator from 1,000 to 1,500. Unlikely that you run into problems, but if you do for big projects, please let us know.

Compiler Hints

The syntax for compiler hints like #require, #use, ... has been relaxed to allow leading white space before the '#'.

Bugs

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

SmartTableModel

Already mentioned in a previous blog post was Dave Baggett's SmartTableModel. Like most of the recent contributions in qooxdoo-contrib, this one has also seen some activities lately, e.g. by Fritz Zaucker, who added another demo. Try his searchAsYouType demo, as well as Dave's default demo.

Bye!

Yesterday we have found solution for a really annoying problem. The problem was that we didn't receive mouse events during drag operation in IE and Firefox if the cursor left the browser viewport. This was especially a problem for our scroll bars. Since qooxdoo 0.8 we render scroll bars using qooxdoo widgets. If the scrollbar was near the browser's edge and the user dragged the scroll bar knob outside of the browser window, scrolling just stopped. Thanks to qooxdoo user Petr Kobalíček, who pointed out that other frameworks can handle this situation, this issue could finally be resolved.

You can see the difference in this screen cast:

A basic building block for drag operations in qooxdoo is a concept called mouse capturing. It was fist introduced by Microsoft with Internet Explorer 5 but unfortunately no other browser vendor has implemented it (MSDN). Mouse capturing allows web developers to tell the browser that all mouse events should be dispatched on the same DOM element. This is especially useful for drag operations or menus, when all mouse events should go to the dragged element even if the mouse cursor is not directly above the element.

This can be easily demonstrated by looking at a simplistic drag and drop implementation:

 
function draggable(element) {
    var dragging = null;
 
    addListener(element, "mousedown", function() {
        var e = window.event;
        dragging = {
            mouseX: e.clientX,
            mouseY: e.clientY,
            startX: parseInt(element.style.left),
            startY: parseInt(element.style.top)
        };
        element.setCapture();
    });
 
    addListener(element, "losecapture", function() {
        dragging = null;
    });
 
    addListener(element, "mousemove", function() {
        if (!dragging) return;
 
        var e = window.event;
        var top = dragging.startY + (e.clientY - dragging.mouseY);
        var left = dragging.startX + (e.clientX - dragging.mouseX);
 
        element.style.top = (Math.max(0, top)) + "px";
        element.style.left = (Math.max(0, left)) + "px";
    });
};
 
draggable(document.getElementById("drag"));
 

open demo (works only in IE). While dragging try moving the cursor out of the browser window.

In the mousedown handler the current mouse and element position is stored in a drag session and then mouse capturing is started. From this point on all mouse events will be dispatched on the dragged element even if the mouse cursor is not over the element. The mouse can even leave the viewport as long as the mouse button is pressed. Mouse capturing ends when the mouse button is released, an alert box is opened or the browser loses focus. Note that all listeners can be attached directly to the element.

To get the same behavior in non IE browsers is a little bit tricky because none do support mouse capturing. For this reason we cannot attach the mousemove listener to the dragged element. Instead we need to attach it to the document. Since mouse events bubble up the DOM tree the document will receive all move events. One problem with this approach is that while bubbling up an intermediate event listener might manually stop the bubbling by calling stopPropagation. In this case the event would never reach the document and the drag would be broken. To fix this we have to attach the listeners to the event capturing phase. This can be easily confused with mouse capturing but it has nothing to do with it. In the W3C DOM event model bubbling events have two phases. First in the capturing phase the event bubbles from the document down to the event target. Afterwards in the bubbling phase it bubbles back from the target to the document. The bubbling phase is much better known because IE doesn't support the capturing phase at all. If the mousemove listener is added to the capturing phase of the document no other listener will be able to block it.

 
function draggable(element) {
    var dragging = null;
 
    addListener(element, "mousedown", function(e) {
        var e = window.event || e;
        dragging = {
            mouseX: e.clientX,
            mouseY: e.clientY,
            startX: parseInt(element.style.left),
            startY: parseInt(element.style.top)
        };
        if (element.setCapture) element.setCapture();
    });
 
    addListener(element, "losecapture", function() {
        dragging = null;
    });
 
    addListener(document, "mouseup", function() {
        dragging = null;
    }, true);
 
    var dragTarget = element.setCapture ? element : document;
 
    addListener(dragTarget, "mousemove", function(e) {
        if (!dragging) return;
 
        var e = window.event || e;
        var top = dragging.startY + (e.clientY - dragging.mouseY);
        var left = dragging.startX + (e.clientX - dragging.mouseX);
 
        element.style.top = (Math.max(0, top)) + "px";
        element.style.left = (Math.max(0, left)) + "px";
    }, true);
};
 
draggable(document.getElementById("drag"));
 

open demo

If a mouse button is pressed and dragged out of the browser window, Firefox will continue to fire mouse events on the document. Opera, Safari and Chrome are a little more tolerant and fire the events on the document.documentElement as well. For this reason we must attach the listener to the document and not the document.documentElement or document.body.

Because if its usefulness we emulate the IE mouse capturing behavior in our cross browser event handling layer. The fix for IE was to call the native setCapture method. Since we used the emulated mouse capturing support for IE as well we've lost the side effect of receiving mouse events when the mouse left the browser window. In Firefox we just had to switch the event target from document.documentElement to document in our generic mouse event handler. With both fixes in place, mouse capturing and drag and drop operations now really work as expected on all supported browsers.

Here's another roundup of qooxdoo happenings. This time we'll start with one of the most important parts of the framework, i.e. the tool chain, more precisely the Generator:

Dependency Analysis

An essential part of the work of the generator is finding dependency relationships between classes. You throw a few classes at it to start with (like the main application class of your app), and it will work out which other classes are necessary to make the whole application work. If it finds unknown classes in your code it would spill out "! Unknown classes referenced" warnings. But these warnings were not entirely reliable, partly due to stale cache information. If a required class was missing, you could add it to your application and the generator would still produce the same warning. On the other hand, if you removed a class that had been detected before, the generator might silently ignore that it is now missing. This has been fixed, along with other omissions, where the generator e.g. would silently skip existing dependencies in the code, so both the depth of the analysis as well as the reliability of the cache has been increased. The classical #ignore compiler hint is supported again, so you can switch off the "unknown class" warning for global references you know are ok. As a payoff, the new implementation is more demanding in terms of run time. But once the cache has been populated by relevant dependency information, you won't notice any difference.

Chrome Frame

You've surely heard the following news: Google published a plug-in called "Chrome Frame" for Microsoft's Internet Explorer 6, 7 and 8. This plug-in makes it possible to use the JavaScript and rendering engine of Google Chrome instead of the Internet Explorer originals. The plug-in can be downloaded and it comes with documentation.

There has been quite some debate and lament, on the net as well as among the qooxdoo community, about the usefulness of Google's approach. While at first it might appear to be a brilliant idea to get rid of IE's deficiencies and inferior performance, it does have some drawbacks. For instance, in a corporate environment, would the system administrators now install such a 3rd party plug-in into IE, given that they didn't upgrade or switch browsers before (for whatever reason)? In other scenarios, though, this might be a chance to keep IE running for some corporate legacy apps, while offering new web 2.0 intranet solutions in the same browser users are already familiar with. Well, who knows how successful Chrome Frame will be in the long run ...

Anyway, when we heard about the plug-in, we had, of course , to test Chrome Frame to find out if qooxdoo runs in it without any problems. Therefore we installed the plug-in on one of our test computers and ran the nightly test environment. Good news is: qooxdoo seems to run without any problems. The plug-in behaves like its big brother (i.e. Chrome 4), but appears to be a tiny bit slower.

Due to the positive test results we are currently thinking about adding the following meta tag to the qooxdoo skeleton applications:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

So each custom application, typically built upon those skeletons, would always be rendered with Chrome Frame if the plug-in is installed. Is that something you would expect, so that it's a welcome feature addition? What is your experience with qooxdoo in Chrome Frame? Oops, I just stumbled across a discussion on the Frame mailing list, where qooxdoo user John Spackman reported some potential issues with AJAX calls? Anyway, we'd be glad you all shared your experience and opinion about the meta tag with us.

Bugfixes

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

Community

Contributions galore... three more additions this week in qooxdoo-contrib , read on ...

cometd

This is a wrapper of the client-side part of the well-known Cometd protocol in qooxdoo, contributed by Christian Boulanger. He says:

"[...] ever since Alex Russell coined the term "comet" for a server push technology
for http, I have been fascinated by the idea. Being dissatisfied with the
responsiveness of my app, I have long wanted to use it in qooxdoo - but
without having the full overhead of including yet another javascript
framework like dojo. I have finally gotten around to porting the client
javascript code to qooxdoo."

You can find the top-level hook to this contribution on its entry in the contributions overview. There is still some code porting to be done, and Christian appreciates support regarding the transport layer. Check the mailing list if you feel like jumping in.

jqxPlot

Fritz Zaucker has provided jqxPlot, a demo application to showcase the integration of the jqPlot plotting library into a qooxdoo application. This is not only interesting for those wanting to bring charting to their qooxdoo apps, but are interested in integrating foreign libraries in general. Have a look at his nice online demo.

jqxPlot Demo

CollapsablePanel

Also from Christian Boulanger, there comes CollapsablePanel, an accordion-style widget which allows you to open multiple items at the same time; this has already received lively feedback on the mailing list. Not only that. Matthew Gregory, another qooxdoo power user and contributor (e.g. of the TileView widget), helped in advancing Christian's solution based on some previous implementations of his own. There are quite some activities around the CollapsablePanel right now. For the time being, you can check Christian's original demo and also the current state of the improved demo.

Collapsable Panel Screenshot

With all the new stuff to try out, don’t forget to check back for next week's regular status update.

Lets take a look back at another enjoyable week in qooxdoo:

Native Scroll Bars

Since qooxdoo 0.8 we render the scroll bars as pure qooxdoo widgets. This has the advantage that one has full control over the behavior and theming of scroll bars. Unfortunately, it is not possible to always replace the scroll bars with qooxdoo scroll bars. Especially the areas that are not fully under control of the layout engine still show the native scroll bars. Examples for that are HTML embed, IFrame and TextArea widgets. Since this mixed look in a more complex app can potentially irritate users we have now added an option to render all scroll bars as native scroll bars. There is a global setting qx.nativeScrollBars which determines the kind of scroll bars used throughout the application.

Both kinds of scroll bars

Drag and Drop events now bubbling

We only recently realized that drag and drop events in qooxdoo 0.8.x were not bubbling. This is different to the drag and drop events in qooxdoo 0.7 and the proposed drag and drop specification in HTML5. Since there are several uses cases which require bubbling drag and drop events, we have now turned those events into bubbling events. Note that this fix changes behavior and can lead to problems with existing code if draggable or droppable widgets are nested. In these cases the old behavior can be restored by adding stopPropagation() calls to the end of drag and drop event handlers.

Label API adjustments

In order to further standardize the API, the methods getContent() and setContent()in qx.bom.Label and qx.html.Label have been deprecated in favor of getValue() and setValue(), bringing them in line with qx.ui.basic.Label. Unfortunately, this inconsistency hasn't been noticed earlier, but we felt it needed to be corrected asap to account for all the cleanups in this area made towards 0.8.3.

SVN trunk cleanup

Talking of 0.8.3: in that release we had quite a number of API changes as mentioned, and to support the transition of existing code had included a lot of run-time deprecations. While working towards the 1.0 release now, it was time to get rid of all deprecated code and also the legacy sources that were kept in the framework from 0.7.x. It was quite some work but finally and successfully, we got the SVN trunk almost deprecation free, including all the qooxdoo apps and components. The SVN revision before removals is r20219 just in case you'd need it. If you encounter any problems, please do not hesitate to file bug reports, thanks.

Bugs

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

Tartan Blueprint

Dan Hummon from Tartan Solutions has added the Tartan Blueprint contrib. Blueprint is about form serialization to JSON. In his announcement, Dan writes

"This is primarily a serialization engine for the creation of forms. We have
created a JSON format that describes forms, scripts and functions on
objects. This is a similar approach to some of the UIDeclaration or
qxTransformer work. I'm hoping to get some feedback on our solution."

See here for the full announcement. Among other things, Dan has created a specialized Playground application that let's you evaluate Blueprint JSON data immediately. The project's current home page is here.

Not surprisingly, but impressive nevertheless, there is a designer component that lets you create forms interactively, and which creates Blueprint JSON in the background. - Way to go, Dan!

Outlook

In next week's blog post we'll try to showcase some of the other contributions that have entered qooxdoo-contrib just recently or are currently being completed. It's great to see so many high-quality contributions for qooxdoo to appear. If you feel like contributing a project yourself, feel free to do so. Keep in mind that it doesn't need to be big, though, just useful for or "colorful" within the qooxdoo community.

That's it for the moment, see you around next week.

Welcome to another summary of activities that took place during the week:

The Ajax Experience

But first, here is some feedback from Fabian's participation at this year's TAE:

"Last week I (Fabian) represented qooxdoo at The Ajax Experience in Boston. On Sunday Dan Hummon, Derrell Lipman and me did a tiny qooxdoo user group meeting in a very familiar atmosphere at Derrell's home. Thank you Derrell for the invitation, it is always exciting to meet and talk to qooxdoo users and co-developers in person.
You can check out the slides from slideshare. I expect the recorded audio to be published on ajaxian.com later this year."

Commands

The former commands' main feature was merely an abstraction of keyboard inputs in a central place. But we wanted to extend the feature set of the command to also address requirements that are found in a typical ui layer. Something that has also been brought up before by some qooxdoo users. The main idea was to add some common properties of command-using widgets to the command themselves and let the command configure the referencing widget. Therefore, we moved the original (low-level) command from qx.event.Command to qx.bom.Shortcut to make it more visible in the bom package. The new (ui-level) command, which includes the new properties as mentioned, can be found in qx.ui.core.Command.

Unfortunately, the new demo, which is to show you the benefits, is currently broken in the online snapshot of the devel version. Till that is fixed, you may want to check out the SVN trunk version, sorry for any inconvenience.

UPDATE: The new demo, which is to show you the benefits, is online.

New test jobs

Two new generator jobs have been introduced: test-inline and test-native. Unlike the regular test job, which creates a test application inheriting from qx.application.Standalone, these will generate test applications extending qx.application.Inline and qx.application.Native, respectively. This allows developers working on Inline or Native applications to run their unit tests in the same kind of application. See the Test Runner wiki page for details.

Generator

A small, but hopefully helpful snippet has entered the wiki, about how to create a customized API viewer that includes the class documentation of additional qooxdoo libraries and contributions you might use in your application. The page about the default generator jobs has been revamped, and now includes a section about so called includer jobs, jobs that are not directly runnable by the generator but can be used to customize other default jobs.

Bugfixes

Quite a number of bugs were fixed for the MenuBar, e.g. #2806, #2813, #2826, #2827. As usual for a complete list of bugs fixed during the last working week, use this bugzilla query.

Smart Table Model

Dave Baggett has released his Smart Table Model contribution. In his announcement he writes:

"This should function as a drop-in replacement for the standard Simple model, but offers a bunch of new features that are especially useful for big and/or
complex tables. It was inspired by Dan Hummon's Filtered table model, but is
a complete rewrite from the ground up. Migration to this model should
address all of the filed issues with the existing Filtered table model. The
filtering mechanism works completely differently, however, so if you use
those capabilities you will need to change your code a bit."

See here for the full announcement.

WebTech conference

If you haven't heard about the WebTech yet, a newly introduced German web conference, you should check it out: it takes places on November 16 - 18, 2009 in Karlsruhe, were most of the core framework team at 1&1 is located. If you are interested in meeting the team (at least some of us will be around), either at the conference or for a decent after-conference beer and chat, just let us know.

That's it for today, see you around next time.

Welcome! It is one week after qooxdoo 0.8.3 saw the light of day, thanks for all the feedback we received so far. Keep it rolling! But, there is a road ahead and there is no standing still, so here we go...

Framework

Data binding

A key feature of the whole qooxdoo data binding layer is the data array, an array which fires events on every change. This is so important, because the binding needs to know every change to get all the data synchronized. We improved the array further more and fixed some minor issues. Additionally we experimented a bit with defineSetter and defineGetter for accessing the array items. We did get it running, but not very fast. And as long as defining the accessors is not available in all major browsers, we can't use it.

Another focus this week was to fix some issues in the list controller in combination with filtering. Due to the very complex binding structure, it was quite hard to get it working, but we finally managed it how it is supposed to be.

We introduced the modelSelection in the framework last week for all widgets handling a selection. This model selection was not really fitting into the binding landscape so we made some changes to get it into a state where it is easy bindable.

CSS color "grey" in Internet Explorer

The bug report #2766 shows that the British English spelling of the color name "grey",  which is a valid spelling for our current property system, makes problems in Internet Explorer. But what happens if the British English spelling is used?

If the value is set to the DOM element like

element.style.cssText = "background-Color: grey;";

IE6 and IE7 ignore the value and the background color isn't set on the DOM element. Only IE8 shows the background color. Why? Because the British English spelling isn't supported in IE6 and IE7, only the new IE8 supports both spelling forms.

But if the color is set like this

element.style.backgroundColor = "grey";

IE6 and IE7 stop with a script error: "Invalid property value". This stops the script execution which isn't really nice. Therefore, we decided to allow only the gray (American English) spelling, which is supported by all browsers.

Bugs

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

Search in Demobrowser

With every new feature, qooxdoo's Demobrowser is getting more and more demos. Currently, we have more than 230 demos available in the app. With that huge amount of demos, it was about time to introduce a search for the demos.

Tooling

Internationalization Data

A new experimental feature was added to the generator, to support forking out of internationalization (I18N) data in a generated application. I18N data for any app, currently translation mappings and CLDR data (like the date format), are by default included in the loader/boot package of the application. For big projects, with a lot of supported locales and a lot of translatable strings, this part of the loader can become really large.

To allow a better handling of the I18N data, and to speed up loading of the initial application package in the browser, we have added a configuration option to fork out this data into separate files. See here for more details.

Complex Name Spaces

Increasingly, people are using complex name spaces for their applications. They use things like "org.myorg.webclient" to follow a Java-like notation, or something like "webclient.pro.util" and "webclient.pro.ui" to partition a larger application under a common root. To that end, a new snippet document was added, which highlights some of the aspects of using complex name spaces in qooxdoo.

So much for today, see you around next time.

As planned the Open Source RIA Framework qooxdoo is available in a new release 0.8.3. It is quite a comprehensive release, with many improvements and bugfixes over the previous version. For more info please see the detailed release notes.

Some highlights of this release include:

• New Form Handling
• Unified Selection API
• Advanced Data Binding
• New FlowLayout
• New FlashWidget
• New ThemedIframe
• Global Error Handling
• and more ...

The following screenshot shows some features of the new form handling:

qooxdoo 0.8.3 is one of the best tested and most extensive releases to date. To get an idea, see some indicators for the development and testing that went into this release:

• about 1.700 Commits since last release
• about 300 Bug fixes
• more than 1.100 Unit tests (incl. more than 3.200 assertions)
• about 30 Browsers/OS combinations continuously unit-/GUI-tested
• about 160 GUI-tests of applications, fully automated

It is recommended that users upgrade their existing applications to this latest stable version. Migration should be straightforward (but you should carefully read the migration info in the release notes). As the latest stable version it is also perfect for new users to easily get started with qooxdoo. Download and enjoy the brand new 0.8.3 release.

Thanks to all the fellow developers, contributors and users of qooxdoo for their great support and collaboration!

Welcome back to a weekly blog post.

Renamings

You might have wondered recently about some new names among the core team members? Actually, it had a zero net effect: while Johnny led the way a while ago and took his wife's name upon marriage, it was Alex' turn this time. If you haven't already, get used to Jonathan "Johnny" Weiß and Alexander "Alex" Steitz. Guys, congrats again and the best of luck!

Form handling

If you have followed the recent weekly blog posts, you have surely noticed that we have made a lot of changes and improvements in the area of form widgets and the entire form management. In the course of those changes, we removed the former value property for widgets that manage a selection (e.g. SelectBox, RadioGroup, etc.). We got feedback from the community which liked the previous feature a lot, so we reintroduced it with an enhanced concept. If you are interested in this topic, please take a look at the corresponding issue report and see the comments for details.

Opera 10

You have certainly noticed the final release of Opera 10 this week. It's a modern and fast browser for sure, but it also gave us some headaches. We hit a problem that apparently the RCs had as well, which breaks the TestRunner and the whole browser badly. After some investigation we figured out that Opera 10 crashes if you assign an empty string to the message property of an error. Give the following code a try in an Opera 10 release (Windows or Mac, not Linux) and see the Opera O fall off the cliffs ...

try {
  var e = new Error();
  e.message = "";
  throw e;
} catch (e) {
   alert(e.message);
}

As a consequence of this, we decided to assign the qooxdoo base error a non-empty default message, so this issue won't affect you in the future.

Forum

A while ago we reminded you of the possibility to use Nabble as a web frontend to the regular qooxdoo mailing list. There is even a somewhat experimental embedded qooxdoo forum right within the homepage. When working more intensively with the Nabble forum ourselves, we noticed a few outages in their service, particularly the embedded forum. Since there are a number of you already using Nabble, what's your experience with the quality of their service?

The Ajax Experience

As reported Fabian will do a talk at the upcoming Ajax Experience, September 14-16 in Boston. If you happen to be at the conference (or at least in Boston at that time), it'd be great to have some sort of qooxdoo get-together.

Bugs

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

Release 0.8.3

As announced on the mailing list already, we are in the process to prepare for a release qooxdoo 0.8.3 next week, Thu 2009-09-10. There are still some issues we'd like to address, but certainly it'll be a welcomed maintenance/bugfix release, also given the many existing improvements over 0.8.2. If you happen to be on SVN trunk (or try out the devel snapshots of the online apps that are updated each Friday) and you notice any critical issues, please report them asap so we might consider them for the release.

Thanks for your attention and support. Have a nice weekend.

Welcome back. This is exactly what we said to Alex, Chris and Fabian, who returned from vacation. The core team at 1&1 enjoyed to be complete for about three days, but is now about to send Thomas into his well-deserved vacation...

Automated Framework Testing

You certainly saw the blog post about the efforts we make to continuously test the framework during development. This certainly pays off, resulting in a more stable, higher-quality code base. Also note that this test setup covers a wide range of tests, from API coverage, over code validation, build process, unit tests all the way to simulated interactive tests. This is a good chance to remind you of qooxdoo's Simulator, which allows you to setup and run automated functional tests for your application.

Context Menu

We implemented a new feature of the context menu: it now allows to block the background, when the context menu is shown. To activate this feature use the new property blockBackground on qx.ui.menu.Menu. The widget has two additional properties blockerColor and blockerOpacity to style the blocker used.

Resource Management

qx.util.ResourceManager has been turned into a singleton class. The reason for it was partly to align it with other managers (like qx.util.AliasManager), but also to be able to write mixins with properties for it. The former static methods have been turned into instance methods which you use with the typical singleton idiom qx.util.ResourceManager.getInstance().<methodName>(). The static methods continue to function, but issue a deprecation warning.

The new deprecation warnings in the ResourceManager might silently introduce new load-time dependencies to application code when calling static methods as initializers or in defer sections. We had such a case with calls to the static qx.bom.Stylesheet.includeFile() in the defer section of application classes (see this bug; qx.bom.Stylesheet.includeFile()is callingqx.util.ResourceManager.toUri() internally).

Forum

Many qooxdoo users have already been using Nabble, which provides quite a nice web interface to the qooxdoo-devel mailing list. Check out the regular external forum. This forum has been pimped to become a more advanced embeddable forum including avatars and a few other features. This forum is also available as an embedded forum within the qooxdoo homepage.

Recently we have been trying to use the web interface provided by Nabble more often ourselves, figuring out possibilities to create some sort of workflow (therefore the experimental sections Q&A; and Q&A; (solved)), or introducing some sub categories depending on topics. We just wanted to point out again this alternative to the regular mailing list. You might be interested to have a look at the other possibilities, which also for some handy features, for instance full-text search of previous posts.

Bug Handling

We are in the process of refining, if not redefining, the bug handling process. This not only allows for a more efficient workflow among the core team members. It also makes the entire process more consistent and transparent to everyone involved in the project, particularly fellow commiters, contributors and users. There's preliminary documentation available of the proposed bug handling. The clear definition of workflow stages (named triage, commitment and termination) and individual phases of an issue should benefit all current and future bug handling. Of course, the data within the bug tracking system is not yet fully consistent with the new scheme, but we are going to address that over time. Focus will be on cleaning up and possibly re-attributing the currently open issues, but we'll expect to also go back in history for about one or two releases. So don't wonder and be patient if there's quite some activities in bugzilla in the upcoming days or weeks. The process will be further refined and extensively documented, incorporating your feedback and input, as well as addressing all the questions you might have. You could also be interested to look again at the existing docs on how-to report bugs.

Talking of bugs, here's the regular list of bugs fixed during the last working week, see this bugzilla query.

The Ajax Experience

This year we will be at The Ajax Experience (September 14-16) in Boston again. Fabian will do a talk about how to master large scale applications with qooxdoo. He will present lessons learned from supporting and working on applications like the GMX.com web mail client. If you plan to attend TAE or happen to be in the Boston area, let us know. We could organize a little qooxdoo.beer() meeting in downtown Boston.

That's it for the moment. C U next week.

It is said that "if your software is bug free, you're just not testing enough". With that in mind, we spent quite a bit of time during the last months on our internal testing infrastructure. Let's take a closer look at the results so far.

Since it was first mentioned in a blog post back in January, qooxdoo's automated testing setup has grown and matured quite a bit. As of this week, the testing infrastructure consists of 6 PCs running 4 different operating systems (Windows XP, Vista, OS X and Linux) with a total of 18 browsers, from IE6 all the way up to the latest devel version of Google Chrome. While not every conceivable combination of OS, browser and application is tested,  each nightly test run consists of over 160 individual tests.

Test schedule

Each night all the framework applications are generated, unit tests are run and applications are subjected to simulated interaction tests. Additionally, the framework classes are scanned for missing documentation and checked for potentially problematic code by ecmalint.

A reduced number of tests is also run each Friday afternoon to make sure the week's devel versions of the demo apps are free of show stopping bugs.

Selenium running the Feedreader simulation

Software components

The backbone of the testing system is a test controller script, written in Python: Its first task is to update a local qooxdoo trunk checkout and to run the Generator commands necessary to build the framework applications, api reference and unit tests. Once the apps are ready, the test controller script proceeds to launch a sequence of simulated interaction tests (a.k.a. simulations), each of which logs any errors it encounters.  Finally, the controller script aggregates the test results and generates HTML-formatted reports which are then emailed to the qooxdoo team members.

The simulations leverage Selenium RC, enhanced by the qooxdoo user extensions from the Simulator contribution. These add a number of locators and commands that are used in the simulation code to interact with a qooxdoo application and its widgets.

For example, the Feedreader test mimicks a user selecting a feed item, changing the application language and adding a new feed. After each step, the application is inspected to make sure the action had the expected result.
The Testrunner simulation, on the other hand, features very little simulated interaction: Unit test packages are run, and any test failures or errors are logged.

All Simulations are written in JavaScript and executed in Mozilla Rhino which provides access to the Selenium Java class.

HTML report of the API documentation test

Conclusion

Even though we've yet to further stabilize the infrastructure and to reach some of the loftier goals of Continuous Integration (such as building and testing (almost) continuously rather than just nightly), automated testing already helps us notice bugs faster and has taken at least some of the burden of testing in a wide variety of browsers off the core devs' shoulders. You certainly benefit from a more stable and higher-quality framework.

This is another round of qooxdoo weekly news. Summer and vacation time still take their toll, but the upcoming week will see three core developers returning to the office. So, for this past week let's dash right in...

Form Management

During the implementation of the whole new form layer, some problems showed up using the radio group. The qooxdoo radio group is not a widget, it's an object handling a logical connection of the radio buttons and taking care of the selection. Additionally to that logical connection, the layouting could be interesting for most users. For that, we added a widget called RadioButtonGroup, which handles the logical connection and the layouting of the radio buttons. It can be configured using the qooxdoo layouts. Take a look at the demo to see it using some different layouts.

A quite interesting bug showed up this week in webkit browsers. We figured out that webkit changes the textcolor of disabled textfields. It changes the default qooxdoo disabled color to something which looked more like the enabled color as you can see here:

To get rid of that effect, we decided to use CSS to disable textfields in all webkit browsers. The CSS Attributes -webkit-user-modify and -webkit-user-select in combination can have the same effect as the disabled attribute but without changing the color of the textfields inner font.

Bugs

As usual the complete list of bugs fixed during the last working week can be viewed with this bugzilla query.

Documentation

A new snippet made it into the wiki, offering some advice on running the source version of a qooxdoo app from a web server.

Generator

Combining Images

The key for combining images into a big one has changed significantly, but since most people will not be using this feature it shouldn't affect many.  The motivation behind it was to be more precise when creating the .meta file, which accompanies each combined image. The .meta files used to contain just file paths, but we wanted them to contain image ids, short path suffixes that start with the name space and end in the image name. Consequently, the format of the .meta files has changed too. To achieve this we needed to know where in the file path the image id starts. This is reflected in the new "prefix" sub-keys in the combine-images key. The output file is attributed with such a sub-key, and input files with same prefix are grouped together. This is an incompatible change, so if you are among the rare trunk users who have ImageMagick installed and are creating their own combined images, check out the above link for the new key syntax, and re-generate your combined images.

Community

A new contribution has landed: Cropper, a widget that lets you crop another widget, typically an image, by Tobias Oetiker. Check out the demo. - Way to go, Tobi!

That wraps it up for this time - see you around soon!

Welcome to another weekly status update. This time it is a rather short one, since many members of the core team are on summer vacation. Efforts mainly focused on consolidating individual working areas, evaluating and fixing framework bugs and documentation.

Form Management

The future development plan as posted last week became reality in the last few days: we added a controller for the new form. A new demo shows how to use all the new form goodies including data binding, serialization and validation. The documentation of the controller is also available at the page about form handling.
As a next and somewhat final step, we want to add an additional way to create a form very easily. Likely there'll be some kind of JSON definition for a form, which is then parsed and creates a fully-featured form from its definition. A corresponding task can already be found in qooxdoo's bugzilla.

API docs

Thanks to an excellent contribution by Nick Glencross and some subsequent work, many typos and mistakes in the framework's API documentation were fixed. While at first sight such documentation errors might not seem to be critical, they nonetheless can spoil much of the confidence into the existing API and its documentation. There certainly are enough issues left, so feel free to help resolving them, e.g. by providing a patch file attached to a bug report.

Bugs

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

That's it for the moment. Enjoy a great summer weekend.