QxWT: Find out API changes between Qooxdoo-Releases

While trying to update my qooxdoo wrapper to 1.3. I had the problem that I could find out easily which classes, methods and properties have been added/remove between e.g. 1.2 and 1.3 so that I could adjust my GWT-Wrappers.

This was until Andreas Ecker from the qooxdoo team pointed me to an interesting Meta-Data information the generator spits out for the API-Viewer. It took me about an hour to write a small Java-Programm which created a diff of those .json-Files.

Below you see an example output of a diff between Qooxdoo 1.2 and 1.3.

You can download the small utility from here. The usage is quite simply as long as you have Java installed on your system.

Usage: java -jar qxapidiff.jar -v0 $APIVIEWER_DIR_VERSION_0 -v1 $APIVIEWER_DIR_VERSION_1 [-a 0|1|2]
	* -v0 (mandatory) ... Path to old versions API-Viewers script directory e.g. /home/tom/qx-1.0-sdk/framework/api/script
	* -v1 (mandatory) ... Path to new versions API-Viewers script directory e.g. /home/tom/qx-1.3-sdk/framework/api/script
	* -a ................ Minum-Access-Level for Method diff: 0 = private, 1 = protected, 2 = public
	* -h ................ Prints this message

if you think you can improve it, you are free to do so (e.g. to add constructors and method-arguments to the diff calculation) because you can access the sources from my public SVN-Repository.

I think in future I can use this informations to e.g. write create wrappers or at least their stubs automagically🙂 but until then I need to wrap them by hand.

QxWT released

The qooxdoo-Team just released version 1.2 of their JavaScript-(UI)-Library and so I’ve updated the QxWT-Wrapper for GWT to as well. There’s a new set of virtual-widgets in qooxdoo 1.2 but I decided to not wrap it yet because the API is not finished yet.

You can look at the Demo-Application which presents many of the things available in QxWT If you want to use QxWT in your GWT-Applications you can get it following this link.

QxWT released

Following the release of qooxdoo 1.1 last week. I’ve updated the QxWT-Wrapper to use this version of qooxdoo. The transition was painless because qooxdoo didn’t break existing APIs.

QxWT doesn’t introduce new features or bugfixes because of the lack of time (e4 kept me busy) but naturally inherits bugfixes and speed enhancements from qooxdoo.

You can download the full release from this page or directly using this link always pointing to the latest version. I hope I can spend more time on QxWT but as said e4 is taking a lot of my free time and help fixing the not wrapped qooxdoo-API is naturally always welcome.

Take a look at the Showcases here to see how powerful QxWT in combination with qooxdoo is.

It’s release time – QxWT and GRaphael


At the start of the year I promised to release Version of QxWT at the end of Febuary and doing releases on time is one of the most important things so that people can start to trust into your project. You can download the released code from the project release website or directly through this link.

This release comes with the following major features:

  • Full support for Qooxdoo-Databinding
  • Advanced GWT-Features to e.g. Subclass JSNI-Wrappers and overload JavaScript methods in Java
  • Integration into the qooxdoo-Toolchain to create optimized JavaScript
  • Many bugfixes and not wrapped methods in
  • Integration of GRaphael to create advanced graphics, animations and charts ontop of SVG and VML using Raphael

The following features beside bugfixes are planned for the next release due in the end of April:

  • Wrapper:
    • Integrate into GWT-UI-Binder by allowing to adapt QxWT-Widgets
    • Integrate into GWT-RPC-Services
  • Eclipse-Tooling
    • Add Project Creation Support to easy setup a QxWT-Project
    • Add Support to control qooxdoo-Toolchain and create a deployable Application


To get support for advanced grapics and animation support I started writing a JSNI-Wrapper for Raphael. QxWT comes with an addon module which provides direct integration of GRaphael into QxWT-Applications. The wrapper is in it’s early stage and the API in the flow.

The current usage in QxWT looks like this:

QxRaphaelWidget widget = new QxRaphaelWidget(200, 200) {
  protected void init(RPaper paper) {
    RElement el = paper.image("/image.png", 50, 50, 100, 100);
    el.attr( new RAttribute("opacity", "0"));
    el.animate(1000, new RAttribute("opacity", "1.0"));				

Which creates an image whose opacity attribute is animated from 0 – 1.0 in 1 second, advanced transitions, gradients and much more are possible as well. You can download the released code from the project release website or or directly through this link.

A real world example

To show the potential of all this technologies I’m working on a real world example which simply allows a user to manage Photos, create Online-Presentations and in future also create printable PDF-Files (e.g. a calender, photo-album, …).

QxWT – Realworld Demo

Tomorrow I’ll release QxWT as I promised at the start of the year. To show people the power of QxWT and what can be achieved by using it, in conjunction with Eclipse-Tools like EMF and Teneo, I wrote an example application on the last 2 weekends.

First of all using all those OpenSource-Technologies together to create an application is simply fun. It’s been a long time since i worked with Hibernate but with Teneo, I really only needed know EMF and learn to use 2 or 3 JPA-APIs to query for stuff. This shows something I told many people already. EMF is not only useable in RCP-Application, it doesn’t even depend on OSGi. I used it at the backend for the Hibernate integration in an ordinary Jetty-Servlet-Container.

The application looks like this:

  • Open a Image-Album
  • Overview of images in the album
  • Editing meta data to images
  • Creating a custom Online-Presentation
  • Running Presentation

The whole application is not completely ready, I hoped to be further but you can try it out:

The application uses the following opensource libs:

  • Frontend
    • QxWT (EPL/LPGL)/qooxdoo (EPL/LPGL)
    • GRaphael (LGPL/EPL)/Rapael (MIT)
  • Backend:
    • EMF+Teneo (EPL)
    • Hibernate (LGPL)
    • PostgreSQL (MIT)

I have not tested this thoroughly (I only took a look on Firefox, Safari, Chrome and Opera on Mac OS X – Opera seems to have issues with images) so please don’t expect to run everything 100%. The code of the example-application is part of my SVN-Repository but NOT released under an OSS-License! Still you can take a look and learn how to use the QxWT-API.

Things I plan to add in the weeks to come:

  • Finish current features and fixing bugs
  • Adding more presentation features (Image-Transition, Drop-Shadows, Animation, …) using more Features of Raphael
  • Print support to create printable Versions for Calendars, Photo-Books, …

So stay tuned for the release announcement of QxWT tomorrow where I’ll explain features coming with this release and features I plan to add in the next releases.

QxWT and other cool stuff

As the blog title suggest I’ve uploaded a first release candidate for the QxWT which is going to be released on about a month.

The most important new features coming with this release:

  • Postprocessing to use qooxdoo toolchain
  • Support for Databinding

Beside this I am in need of a browser charting library and played around a bit with Raphael this weekend which also has a very tiny charting module which is released under MIT. Because of my QxWT-work I’m quite good now in writing JSNI-Wrappers and so I did that for Raphael. You can look at the result of this here.

The wrapper is released under EPL and LGPL and I guess QxWT will in cooperate this library in

QxViewers – The first steps towards a UFaceKit-Webport

I’ve talked a lot (1,2,3,4) lately about my progress on QxWT towards release Now that all the codeing is done more or less I can restart working on my master plan:

Single APIing for Web and Desktop programing use Eclipse Libraries like Eclipse Databinding – In short UFaceKit

Having completed the SWT-Port more or less since some time, having portotype implementations for Qt and Swing (to check if the concept can be transfer easily to other Desktop-UI-Frameworks) the missing thing is a port for a Web-UI-Framework.

The problem is in the Web/GWT-UI space that GWT itself comes with a very restricted UI library missing important things like Table/TreeTables for example and one needs an external framework. I couldn’t find a framework that fully satisfied my needs (most important a clear, reliable license scheme allowing me to use it in commercial applications) so I started my work on QxWT and now that this framework enters in a stable phase I can once more shift sources back to UFaceKit.

To get to a first UFaceKit-Webport I have the following workitems:

  1. Done: Eclipse Databinding 3.5.2 for GWT – (no builds until Eclipse 3.5.2 itself is declared)
  2. In progress: UFaceKit-Viewers for QxWT-Structured-Controls – this gives automagically support for ufacekit-viewers-databinding because UFaceKit-Viewers are split in generic and widget-toolkit parts and ufacekit-viewers-databinding only talks to the generic part
  3. Not started: UFaceKit-Wrapper for QxWT – the thoughest thing might be to write write the native layouts

As the blog title suggests I’ve made good progress today and I can show off the first demo results from this work. The implementations are not finished yet but for people who are familiar with JFace-Viewers lines like the following might look familiar (beside the obvious Java5 features of UFaceKit-Viewers):

 * Combo Viewer Setup
ComboViewer<Person, Collection<Person>> viewer = new ComboViewer<Person, Collection<Person>>();
viewer.setContentProvider(new CollectionContentProvider<Person>());
viewer.setLabelConverter(new LabelConverter<Person>() {
  public String getText(Person element) {
    return element.getFirstname() + ", " + element.getLastname();

Collection<Person> ps = new ArrayList<Person>();
for (int i = 0; i < 300; i++) {
  ps.add(new Person("First " + i, "Last" + i, i));

 * TableViewerSetup
TableViewer<Person, Collection<Person>> tableViewer = new TableViewer<Person, Collection<Person>>();
tableViewer.setContentProvider(new CollectionContentProvider<Person>());

TableViewerColumn<Person> col = new TableViewerColumn<Person>(tableViewer, "Firstname");
col.setLabelConverter(new LabelConverter<Person>() {
  public String getText(Person element) {
    return element.getFirstname();

// ...
Collection<Person> ps = new ArrayList<Person>();
for (int i = 0; i < 300; i++) {
  ps.add(new Person("First " + i, "Last" + i, i));

 * TreeViewer setup
TreeViewer<Person, Collection<Person>> viewer = new TreeViewer<Person, Collection<Person>>();
viewer.setLabelConverter(new LabelConverter<Person>() {
  public String getText(Person element) {
    return element.getLastname() + ", " + element.getFirstname() + " ("+ element.getAge() + " years)";

viewer.setContentProvider(new ITreeContentProvider<Person, Collection<Person>>() {
  public Collection<Person> getChildren(Person parentElement) {
    return parentElement.getChildren();

  public Person getParent(Person element) {
    return element.getParent();

  public boolean hasChildren(Person element) {
    return element.getChildren().size() > 0;

  public void dispose() {

  public Collection<Person> getElements(Collection<Person> inputElement) {
    return inputElement;

  public void inputChanged(IViewer<Person> viewer, Collection<Person> oldInput, Collection<Person> newInput) {

The widgets look like this:

I’d like to point out once more that UFaceKit is structured in a way that you can use all parts independently from each other. So if you are in need to a Databinding-Framework for GWT and a light weight Domain-Technology like UBean then you can use them, you only need Java5 ready viewers for SWT and Databinding integration, … all of them are useable standalone with minimal dependencies.

Beside that I’m still struggeling with setting up a build for the SWT-Port on the Eclipse-Servers so that people can start consume stuff from there but that’s a problem many small project suffer.