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.