Welcome to latest installment of our weekly activity report. Several of us continue to be engaged in a big in-house qooxdoo project, at least part-time. Here is what else happened.

Framework

Theming

The resource key in decoration and icon themes was too limited. It was only possible to set exactly one resource directory. It has been replaced by the new alias key, which expects a map as value. The map keys are the alias names and the values the corresponding resource directories.

Just as ordinary qooxdoo classes, themes do support mixins. However it is not possible for mixins to override existing keys. To allow explicit overriding of keys theme mixins can now be included using the patch key.

Decorators

The "Uniform", "Single", "Double" and "Beveled" decorators now also support setting the background image position.

New features

• It is now possible to change the position of the icon of a TabButton in the TabView widget.
• We have added a new event (beforeContextmenuOpen) which is fired before a context menu is shown (#1257).
• If the size of the DOM element for an inline application is not set and the dynamicX/Y settings are used, an error is thrown (#2342).

Bugs

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

Generator

Cache Stuff

The default path of the cache folder has been changed, it's now in a system-dependent temp directory. The system-dependent temp directory will be something like /tmp on *ix systems, %HOMEDRIVE%%HOMEPATH%\Local Settings\temp on Windows XP, and something even more intuitive like /var/folders/-t/-tPw69jr2RWkyU+1YrJNvU+++TM/-Tmp- on MacOSX. You can always override this default by setting the CACHE macro in the let section of your local config.json file. The reason to introduce this was simply to support multi-application development on the same machine, getting the cache out of the way in the individual application, and benefit from cache re-use across applications.

The new default location takes advantage of another novelty, the TMPDIR system macro. System macros introduce a new breed of macros that can be referenced without ever being explicitly defined in a configuration file, since the system, i.e. the generator, will provide a definition for them. Let's see how they evolve.

If you allow multiple applications to access the same cache, there is a chance that you have classes with same names from different applications. In order to accommodate this, id's for cache objects have been changed to better reflect the context they come from. So for instance, if you are using the same qooxdoo installation for multiple applications, you will get the benefit of cached framework classes across applications. If, on the other hand, you fancy to use different qooxdoo installations on the same machine, e.g. with different versions, their cache items will be different, and will not be used interchangeably.

Configuration

A new key packages/loader-with-boot, if set to false, allows you to separate loader information from class code. (This will only make sense to people who actually need it, so don't worry about it).

Contributions

HtmlArea

There are two new releases available of the HtmlArea: 0.3 and 0.4. Check out the corresponding blog post for detailed information.

In short: the new 0.3 release works together with 0.8.2 and newer while the 0.4 release targets the 0.7.4 release. (Yes, the lower HtmlArea version works with the higher qooxdoo version, and vice versa).

Community

qooxdoo.org Changes

We did a bit of tweaking of our online presence at qooxdoo.org this week. The aim is to gain some overall performance. Our demo site was offloaded to a separate port, which should both benefit demo delivery and performance improvements for our other online offerings, like this blog service. The change is supposed to be transparent (well, quite), so don't update your bookmarks. All demo-related links and bookmarks are supposed to remain stable, and we might shuffle things around again in the future.

Left-handed Martin

As it so happens, fellow core developer and baseball catcher hotshot Martin broke his right hand the other day, defending his team's victory on the field. He's sorely missed. All the best, Martin!

That's it for this time. There is another holiday upcoming, so we'll back for daily business on Tuesday. - Have a good time!

What's better than one release? Yepp, getting two release out of the door

This way we want to offer a stable release for both qooxdoo codebases.
Version 0.3 is based on the current 0.8.2 release and version 0.4 is targeted for the legacy release 0.7.4.
Both versions are mainly bugfixing releases with the aim to stabilize the component.

After the release the code base of the 0.3 version will replace the current trunk (0.4 based) to continue the development on a 0.8 base.

Special thanks to Petr Kobalicek for contributing code and helping with the migration to 0.8 and to John Spackman for hunting some bugs and starting to work on the HtmlEditor contribution.

Interesting links:

• 0.3 Demo
• 0.4 Demo
• Online Overview
• Project documentation
• Download at SF

Give it a try and let us know if you like.

Welcome to another weekly status update. This has been quite a short working week for most of the core developers here at 1&1. Due to yesterday's national holiday, many chose to take this Friday off for a long weekend.

Roadmap

For the next few weeks and months we will increasingly be involved in supporting in-house qooxdoo app development. This is a great thing to happen, as this kind of consulting is an invaluable feedback channel for getting to know real-life framework use as well as experiencing missing or impractical features. The possibilities to use qooxdoo as the framework of choice for many different scenarios within the enterprise have increased much over time, last year's 0.8 release clearly being a landmark.

Of course, this engagement has to be taken into account for the mid to long term release planning. Therefore, the roadmap has been adjusted accordingly. Over the next few months working towards a 0.9 release (targeting October 2009) and finally a 1.0 release still by the end of the year clearly lets us continue and intensify our efforts to stabilize proper API - while carefully deprecating inconsistent or impractical API. You are requested to actively support this process of making the framework more mature by submitting your input about problematic API as well as new or extended features that are expected to require the API to be adjusted.

Form API

As promised last week, we added a manual for the new form API to the wiki. If you see some missing parts in the documentation, feel free so send in feedback (mailing list or bug tracking preferred). Please keep in mind, though, that there are a number of new features still to come, particularly to allow for convenient form serialization, etc.

Deprecation

During the process of moving to the new form API, much attention was paid to properly deprecate the existing API. We added some initial documentation to the wiki about how to deprecate different types of changes. This document is not only interesting for those who plan to deprecate things for themselves, but also for all developers who want to know what can be deprecated and what can't and why.

Inspector

The Inspector got a small but handy new feature: The Widgets window can now optionally display the "external" parent/child hierarchy of the inspected application, i.e. only those child widgets added by the application developer through the parent's add() method as opposed to all the children including internal child controls created by the parent widget itself.

In order to achieve this, the getChild() methods of qx.ui.container.Scroll, qx.ui.core.ScrollPane and qx.ui.virtual.core.Pane have been deprecated in favor of the getChildren() method now implemented by all widgets with a public add() method.

Flash Widget

As mentioned in the last weekly blog post we were about to fix the reload issues of the re-introduced Flash widget. Unfortunately, the first attempt of implementation, i.e. to change the visibility method, would have created more problems than it could have probably solved. So we decide to revert to the old implementation and fix this issue with another idea.

By writing an unit test for Flash's ExternalInterface in order to check the two-way communication between ActionScript and JavaScript, we founded out that the ExternalInterface is no longer accessible when the browser gets minimized, another tab gets opened or the user locks the screen. Any Flash experts out there that could provide some input for fixing this issue? Is this a limitation of the browser integration of the Flash plugin? Workarounds? Any help is appreciated.

Bugs

As always here is the bugzilla query for past week's bug fixes.

Data binding

The new data binding feature, which was introduced as an experimental layer in the last release, gathers quite some interest. It is great to see many users work intensively with it and send back feedback and requests. Of course, there can never be enough feedback on such an important concept and its corrresponding API and implementation. If you haven't tried out qooxdoo's data binding, please do so. It is to dramatically influence the way we all write qooxdoo applications in the future.

One of the most active users is Christian Boulanger, who started just recently to add data binding to Table as well as TreeVirtual. His implementation is part of his contrib project qcl. He also provided a nice online demo, so check it out. Martin, creator and maintainer of qooxdoo's data binding layer, is going to have a closer look and eventually collaborate with Christian to come up with an implementation that fits the existing framework feature. Keep up the good work, Christian.

Community Choice Award

Oops, you forgot to vote for qooxdoo to receive one of the 2009 SourceForge Community Choice Awards? No worries, just click on the image below and submit the subsequent form. We thought that qooxdoo best fits into the following two categories, so it would be great you would choose them as well to have votes to cumulate:

• qooxdoo for Best Visual Design
• qooxdoo for Most Likely to Change the Way You Do Everything

Don't forget to show your friends and colleagues how you feel about your favorite project! Get the word out using your social network. If you like you can add a nomination button to your website using this code:
<br /> <a href="http://sourceforge.net/community/cca09/nominate/?project_name=qooxdoo&project_url=http://qooxdoo.org/"><img src="http://sourceforge.net/images/cca/cca_nominate.png" border="0" alt="" /></a><br />

Thanks for your vote. See you around next time.

Welcome to another round of news and tidbits from the qooxdoo team.

Framework

Decorators

Since version 0.8 of qooxdoo we have the Grid decorator. The Grid decorator can be used to set an image background, which scales the inner parts but leaves the border images intact. The grid is very powerful but in some cases it might not be necessary to resize the widget in both dimension. For the special case, where a widget is only stretched in one dimension we have added the HBox and VBox decorators. They use three images and only scale the middle image. In comparison to the Grid decorator, the HBox/VBox decorators require 6 DOM elements less.

Flash Widget

The first stable implementation for the Flash widget is finished. This implementation is marked as experimental, because the API could change until the implementation is finalized. We also implemented a demo that shows some features, e.g.  two-way communication with ActionScript and JavaScript.

During implementing the Flash demo an issue occurred with reloading plug-ins when the widget is hidden and afterwords shown (bug report #2367). We will fix this issue until next Friday, after intensive testing.

Null is not Null

A funny issue occurred this week, by running some unit test with IE. A null returned by the DOM isn't the same like a null from JavaScript. If you run this code no error occurs:

var value = null;
alert(value instanceof Object);

But running this, which also set null to value:

var value = document.getElementById("NoElement");
alert(value instanceof Object);

Throws an exception "object required" in IE, so be careful with checking null values from DOM.

Form API

The finals steps have been made towards the new form API. In sum, 28 classes have been changed. 15 of them got an invalid state and with that also a special look and feel to visualize this state. Take a look at the final demo in the demobrowser. But those changes haven't always resulted in a change in the user API. In some cases, only interfaces have been introduced to have the widgets on a consistent basis. To see a complete list of all widgets and the implemented interfaces, take a look at the pdf attached to the corresponding bug. We plan to have a wiki page about the form API ready next week which will show the changes we made and how you could benefit from the new API.

Bug fixes

It is now possible to set the center property on a TabButton widget (#2312). Thanks to Matthew who sent us a patch. The SlideBar now shows the correct icon for arrow up and arrow down if it is orientated vertically (#2362).

The search panel of the Apiviewer will scroll to the method, event or property the user searched for. This functionality got broken and is now working again.

Here is the canned query for past week's bug fixes.

Generator

Warnings

The generator spills out a new kind of warnings "Empty expansion for macro...". This refers to configuration macros, the ones you define with the let key.  The motivation was that if you reference macros somewhere in a config file, but they are never assigned a value, this went unnoticed and could lead to nasty and hard to track error behaviour. But the new warning feature currently also leads to some spurious messages, in contexts where incomplete expansion of macros is perfectly acceptable (e.g. during inclusion of  external config files). So don't faint .

Documentation

For those who like to read optional background material, there is a new and rather technical section in the  Generator Configuration Background page about how config files are processed.

Community

SourceForge Community Choice Awards

qooxdoo took up on the challenge and has been nominated for a 2009 Community Choice Award in the following categories:

• qooxdoo for Best Visual Design
• qooxdoo for Most Likely to Change the Way You Do Everything

You can nominate too, so don't forget to show your friends how you feel about your favourite project! Get the word out using your social network. If you like you can add a nomination button to your website using the code below:

So much for today - see you around next time.

A Picture is Worth a Thousand Words

I have already blogged about dependency analysis here, which is used in the background by the generator when creating a source or build version of your application. But once your project reaches a certain size, say with more than 100 classes, it becomes interesting to deliberately track dependency relations among those classes, to keep dependencies confined, establish good modularity, and generally maintain an architectural hygiene.

Probably the best way to view dependency relations is in a visual dependency graph. This is what you get using the dot output format of the dependency logging feature of the generator (key log/dependencies/format). There are several ways to actually view the generated information. There are viewers that can interpret the .dot file format. You can also use the dot program to translate your .dot file into an image in the PNG or SVG format, and then use an appropriate viewer.

... or is it?!

One of the first things you notice is that the generated graphs get big very fast. Even the simplest applications draw in a lot of classes, and the resulting dependency graphs get big, wild and unwieldy. They can be hard to overlook and interpret, so their practical value becomes limited (They're very handy for impressing other people, though ). Even tools start to struggle when urged to display big graphs. So an important step is to limit the amount of dependencies to display.

Load-time dependencies of a GUI skeleton app class

The log configuration offers several ways to do this:

• At first, you should select one of the two "phases" to look at, either loadtime or runtime dependencies (key log/dependencies/dot/phase). For the runtime dependencies there is a caveat here: The generator only records classes as runtime dependencies that exceed the set of loadtime dependencies of the current class. That means that if you choose to include the runtime dependencies only in your graph, you will not see all dependencies that a class has at runtime (e.g. through creating instances of other classes in a method), but only those that are not already covered by its loadtime dependencies.
• Next you should select a root class, from which dependencies are displayed (key log/dependencies/dot/root).
• Dependency logging relies on the standard include/exclude mechanisms of the generator, so probably the most efficient way to get to meaningful graphs is to use the include and exclude keys to include and exclude classes and whole ranges of classes, either with or without their dependencies (with the '=' prefix).
• And finally, you can reduce the graph even further by limiting it to its spanning tree (key log/dependencies/dot/span-tree-only).

Spanning Trees

A spanning tree representation gives you the most compact graphs. The important thing here is that you know how to interpret them. In a spanning tree all original nodes are included, but only enough edges to keep the graph connected. In the context of our class dependencies this means that all classes will be displayed but for every class only one other class will be connected, for which it is a requirement - even if there are multiple classes actually using it! (In graph lingo: Each node has exactly one incoming edge).

Load- and run-time dependencies spanning tree of qx.Class

That means that a significant part of the dependency information is hidden in the spanning tree view. But it is still useful, given these considerations:

• If a class is in the graph you know it will be included in a build since it is required by at least one other class.
• The fact which of those dependency relation is actually displayed in the graph is somewhat arbitrary, and depends on when the required class has been found along the breadth-first search that produced the spanning tree.
• But cutting off the surrounding sub-tree by removing a dependency in an ancestor does not necessarily mean you get rid of of this class. It might still be in the dependency graph due to another class requiring it. Then it will show up in another part of the tree.

Color and Size

The graphs supply color and font size to add additional information. Red edges are load-time dependencies, black edges are run-time. Node colors are blue for small classes, green for medium-sized, and red for the heavy-weights. The font size of the class name scales accordingly. Now what is small, medium and large supposed to mean? This depends whether you look at the file size of the source files, or the compiled sizes of the class (ah, details over details...). In the compiled version small means smaller than about 2K, medium smaller than 8K, and big everything above. In the source version are the thresholds 5K and 20K, respectively. The compiled sizes are used by default since they provide more relevance for the resulting build file, but they can also incure a latency when creating the graph since classes might have to be compiled first, in order to get - well, you guessed it - their compiled size. But you can disable this preference (key log/dependencies/dot/compiled-class-size).

I hope these explanations help to make some use of the dependency graphs, should you care to play around with the feature.

It's Friday, time for another weekly report on qooxdoo.

Framework

Form API

The implementation of the form API took a huge step, although it's not completed jet. The following list shows the wigets which have been changed during the week.

• SelectBox
• CheckBox
• Label
• Button
• CheckBox
• Radio Button (still in progress)

There are still a lot of widgets left. To see some initial work, the form validation demo shows some of the already changed widgets, which have an invalid state and therefore something to show.

Bugs

As always here is the bugzilla query for past week's bug fixes.

Generator

Dependency Logging

Dependency logging has seen some additions. Supported output formats now include two Json-type formats, json, a hierarchical map structure that reflects the console output (basically the class names with two children, "run" and "load"),  and flare, a Json format used by Prefuse Flare's dependency graphing tool, which results in really fancy graphics. Both can be obtained in a compact or pretty formatting. To keep dot files manageable you can limit the radius of the graph around the root class (In case you are looking at the spanning tree the radius is equivalent to the depth of the tree). As usual the latest logging facilitites are reflected in the config key reference. Things are still in flux, so don't build your enterprise around it . There will be a dedicated blog post about dependency graphs shortly.

Community

Sourceforge SVN

We had, again, intermittent problems using our SVN repository on sourceforge.net during the last week and beyond. Ever so often commits or updates would fail with no response from the server or time-outs. But as it turned out, there seemed to be a connection problem on one of the transatlantic backbone lines, where mainly Germany was affected while other parts of Europe and e.g. America were just fine. Although Sourceforge offers quite a few channels for their system status, it was only after several people reported problems on Twitter that we saw reactions from Sourceforge.

qxtransformer

Siarhei Barysiuk wrote in to let us know about hot and new features of qxtransformer, the XML-based approach to qooxdoo GUIs. Besides an all-new-and-shiny online documentation, the specific XML application QXML now comes with a schema generator, so QXML documents can easily be validated. Says Siarhei:

"It means that now we can:
- validate syntax of QXML (with some exceptions)
- get auto completion in Eclipse/NetBeans/IntelliJ IDEA/...
Each tag and each property have description from qooxdoo API (again thanks flexible qooxdoo's tools) and it's really useful when you're working with QXML."

Siarhei is also working on a component model. Way to go, Siarhei! If you are interested in this declarative approach follow qxtransformer on their Twitter stream.

RpcPHP

One of the well-established and often-asked-for backends for a qooxdoo application is the RPC implementation in PHP, the RpcPHP contrib project. This has seen some love recently, thanks to Christian Boulanger. Derrell Lipman, the original creator of RpcPHP, talked about it on the mailing list:

"Christian took my original server and converted it to be much more object oriented. My original version in 1.0.0 is well tested at this point. Christian's version in trunk is known to work for him, but has had little outside testing yet AFAIK. The trunk version is supposed to be backward compatible with 1.0.0 as far as the RPC method implementations go, so moving from 1.0.0 to trunk (or back again) should be a no-brainer."

If you are looking for a backend solution to your web frontend, check it out.

That's it for this week - have a nice week end!