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!

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.

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!

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.

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!

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.

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.

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.

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.

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.