The Missing Manual

We have heard it a couple of times: Users are missing a tutorial a bit more complex than the simple "Hello World" tutorial we already have. Today, we want to close that gap between the first tutorial and the demo applications included in the framework like the Feedreader.

As you sure have read in the headline, we are building a simple twitter application. twitter is a well known service for posting public short messages and has a good API for accessing data. The following mockup shows you how the application should look like at the end.

If you take a closer look at the mockup, you see a window containing a toolbar, a list, a text area and a button to post messages. This should cover some common scenarios of a typical qooxdoo application.

In the first part you'll learn how to create a new application and how to build a part of the main UI. But before we get started, be sure you looked at the "Hello World" tutorial. We rely on some of the fundamentals explained there.

Getting started

The first step is to get a working qooxdoo application where we can start our development. You should have already have the qooxdoo SDK and know how to use create-application.py, so we just create an application called twitter.

create-application.py -n twitter

After that, we should check if everything works as expected. Change the directory to twitter and run ./generate.py source. Now the skeleton application is ready to run and you can open the index file located in the source directory. After that, open the Application.js file located in source/class/twitter/Application.js with your favorite editor and we are set up for development!

You should see the unchanged skeleton code of the application containing the creation of a button. We don't need that anymore so you can delete it including all the listener stuff.

The first part is to create a Window. As the Window contains all the UI controls, we should extend from the qooxdoo Window and add the controls within that class. Adding a new class is as easy as creating a new file. Just create a file parallel to the Application.js file named MainWindow.js. Now it is time to add some code to that file. We want to create a class so we use the qooxdoo function qx.Class.define for that. Add the following lines to your newly created file.

qx.Class.define("twitter.MainWindow",
{
  extend : qx.ui.window.Window,
 
    construct : function()
    {
      this.base(arguments, "twitter")
    }
});

We have created our own class extending the qooxdoo Window. In the constructor, we already set the caption of the window, which is the first constructor parameter of the qooxdoo window. So you already have guessed it, this.base(arguments) calls the overridden method of the superclass, in this case the constructor.
To test the window, we need to create an instance of it in the main application. Add these two lines of code in the Application.js file to create and open the window.

      var main = new twitter.MainWindow();
      main.open();

Now its time to test the whole thing in the browser. But before we can do that, we need to run the generator once more because we added the window class as new dependency. So run ./generate.py source and open the page in the browser. You should see a window in the top left corner having the name "twitter".

Programming as Configuring

The last task of this tutorial part is to configure the window. Opening the window in the left corner does not look so good, so we should move the window a bit away from the edges of the viewport. To do this add the following line to your application file:

      main.moveTo(50, 30);

Another thing we should configure are the buttons of the window. The user should not be able to close, minimize nor maximize the window. So we add the following lines of code in our windows constructor.

    // hide the window buttons
    this.setShowClose(false);
    this.setShowMaximize(false);
    this.setShowMinimize(false);

The last thing we could change is the size of the window on startup. Of course the user can resize the window but we should take care of a good looking startup of the application. Changing the size is as easy as hiding the buttons, just tell the window in its constructor:

    // adjust size
    this.setWidth(250);
    this.setHeight(300);

At this point, your application should look like this.

Thats it for the first part. If you want to have the code from the tutorial, take a look at the project on github and just fork the project.
The next part of the tutorial will contain the building of the rest of the UI. If you have feedback or want to see something special in further tutorials, just let us know!

Another weekly status update fresh from the oven:

TabView focus indicator

There was an open issue for a while now about a missing indicator for keyboard focus of the TabView widget. We now added a nice keyboard indicator to the TabView.

Dispose

We increased the granularity of the qx.disposerDebugLevel, which can help you find memory leaks in your application. There now is an additional level for just warning about undisposed qooxdoo objects without warning for undisposed JavaScript objects.

The following listing shows the levels and their meaning:

• 0: No warnings at all
• 1: Warn for undisposed qooxdoo objects
• 2: Warn for undisposed qooxdoo and JavaScript objects
• 3: Warn for undisposed qooxdoo and JavaScript objects and log every disposed object

Dependencies

A long standing bug has been fixed which forced classes to unnecessarily maintain an explicit require to qx.core.Variant. These explicit requires can now be removed, as has been done for qx.Theme, qx.Mixin and qx.Interface. Previously, the dependency of classes to qx.core.Variant got lost in the source version when variant settings were defined in the build configuration, as the dependency tracker works on the optimized tree, where code blocks for unneeded variant values has been removed - and with it the calls to qx.core.Variant. But the calls would still be there in the source version, so this dependency had to be preserved for source builds, which is the case now.

Bugs

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

Have a nice week(end)!

Welcome to the regular weekly blog post. With all the other highlights during the week, most noticeably the release of qooxdoo 1.0.1, coincidentally at the day of qooxdoo's 5 year anniversary, we'll keep it short:

Patch for qooxdoo 0.7.4 in Firefox 3.6

This week we found out that the legacy qooxdoo 0.7.4 version has an inadvertently incomplete bug fix for the deprecated "getBoxObjectFor" method in Firefox 3.6, which was released a few days ago. We now created a patch to allow qooxdoo 0.7.4 to run as intended, i.e. correctly, in Firefox 3.6.

Download the complete ''qx.html.Loaction'' class file and replace the local one, or apply the SVN diff to the 0.7.4 version. For more details have a look at the corresponding bug report.

Bugs

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

C U around next time.

After the successful launch of qooxdoo 1.0 end of last year, here comes a regular update to incorporate the latest bug fixes and also a number of enhancements.

qooxdoo 1.0.1 is a patch release, meant to be backwards compatible to the previous major release qooxdoo 1.0. No migration steps should be necessary to continue to develop and build your existing apps. Please upgrade to take full advantage of this latest stable release.

From the detailed release notes, here are some of the most important fixes:

• Fixed an issue in Firefox 3.6, which was released last week (01/21/2010). The native scrollbar widgets did no longer react on clicks on the scrollbar buttons. This is a known regression in Firefox 3.6, but fortunately we could find a workaround for this issue.
• Fixed a critical issue that prevented IE to run properly under SSL. See Bug #3305 for details. It is strongly recommended to update to this release, if your application is deployed via https.
• Hiding elements, which use the AlphaImageLoader, can occasionally cause IE to completely black out the screen. We now use a technique described here to fix it.

As the latest stable version it is also perfect for new users to easily get started with qooxdoo. Download and enjoy this brand new qooxdoo release.

That's right. Today we can all celebrate qooxdoo's 5th anniversary.

While it is hard to exactly determine the actual start of a project like qooxdoo, January 27th, 2005 was the day the project was registered at SourceForge, the world's largest OSS development web site. This first official appearance certainly qualifies as the "birthday" of qooxdoo.

As a true open source project qooxdoo used public code repositories right from the start. Everyone that followed the progress of the framework over time, either in a passive or active role, saw some very remarkable steps: after the first official release in early 2005 there have been a total of 27 stable releases of qooxdoo, including some ground-breaking and really innovative packages.

When talking about 2005, it is interesting to note that qooxdoo started a month before the term "AJAX" was even coined. While nobody could really foresee all the hype about Ajax, there was already a clear understanding of the potential if not power of JavaScript and modern, cross-browser applications. And a need for qooxdoo as an advanced application framework to make that vision a reality.

It is our pleasure to thank all the people that kept believing in this vision and made it such a fascinating reality! The support by 1&1 as the initiator and maintainer of the framework is indispensable, employing us as a team of full-time core developers. Working with fellow committers and a large number of contributors is a great every-day experience and always a source of inspiration. You really help making this an outstanding JavaScript framework. Last but not least many thanks to all of you who create impressive applications with it, but don't forget to let us know about weak points to address, and also to tell others about the strong points and the fun in working with qooxdoo.

Lets make it another 5 years of innovation, success and fun of developing and using qooxdoo!

Here comes another weekly status report. This time it is a rather short one, since we were quite busy with bugfixing, roadmap planning and various other stuff.

Native JSON support

Last week we have landed a commit, which adds native JSON support to qooxdoo. There is a new class qx.lang.Json, which has exactly the same interface as the JSON object defined in the EcmaScript 5 specification. All new browsers like Firefox 3.5, Internet Explorer 8, Opera 10.5 or Safari 4 support it natively. In browsers without native JSON support a modified version of Douglas Crockford's json2 is used. This is great news because parsing and serializing JSON is a lot faster in those browsers.

Playground enhancements

Just in case you missed it: There is a detailed blog post about some experimental enhancements to the Playground.

Bugs

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

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

As reported in last week's blog post, we worked further on the features of the Playground, especially on the gist support.

GitHub describes gists as a "[...] simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository". The main idea for the Playground is to be able use those gists as custom code examples.

The implementation of that feature was harder than we thought, because the API for accessing gists is not that well documented and accessible. The easiest way to get a clean API for it was to implement a custom YQL table for accessing the gists. With that table, we can now access the gists using the YQL data store, which is already included in qooxdoo. So getting the gists into the playground is just some lines of qooxdoo code. But getting the gists from the Playground back to GitHub is another problem we decided not to solve, because it would be a lot of work with not that much of an added value.

For accessing the gists in the user interface, we added a special gist menu to the Playgrounds toolbar, which has some special features: First, you can easily enter you own GitHub user name and load your own gists (if you don't have your own gists already, try "wittemann" to to see it in action). You might not want to have all your gists listed in the playground, because not all of them are qooxdoo code! Thus we added a filter which limits the gists shown according to a [qx] in each gist's description. With that, you can easily "tag" your gists as qooxdoo snippets.
As already mentioned, we did not implement an integrated editing feature for gists. But of course, adding as well as editing a gist should be as easy as possible. To satisfy the first requirement we added a button for adding gists to the menu, which opens the GitHub page for adding new gists. The same applies for editing, every gist listed has an additional button, which opens the edit page of that gist on GitHub.

If you use the Playground on a daily basis, you don't want to type in your user name every time. We also thought of that and added cookie support to the Playground. The gist user name, gist filtering and the toggle state of the Playground's syntax highlighting are stored in a cookie and restored every time you start the Playground.

Last but not least, the gists also made it into the URL. Adding #gist=id to the Playground URL will load the gist with the given id on startup. That makes it easy to share code snippets stored on GitHub, even for all versions of Internet Explorer, which have problems handling the very long URLs the Playground usually uses for code sharing.

To wrap it up, we added a couple of new features to the Playgorund:

• bit.ly support for URL shortening
• Loading, filtering and using gists
• Loading gists by URL parameter
• Cookie support for storing some preferences

Give it a try in the latest devel version of the Playground. This devel snapshot may not be all too stable yet, and the recently added features are still experimental. But we wanted to let you try out the features early. Please tell us what you think of the new features and enhancements! Hope you like it.

Welcome back to the first weekly status report in 2010. Of course, this series of activity reports continues to allow you to closely follow the project and its progress.

Applications

Demobrowser

You might have already noticed the filter capacity of the demobrowser. This filter enables you to search for demos with a specific name and some predefined tags. We defined a new search criterion this week by adding the qooxdoo classes that are used by any specific demo application. Now you can search for every demo using qx.ui.form.TextField for example. You can also filter for namespaces or parts of namespaces. If you are interested in all classes of the qx.bom package, just use a 'qx.bom' filter so see every demo using it.

Playground

We took the last week to refactor the whole playground code. This gives us now a solid base for further features of the playground. The first of the new features is an integration of bit.ly, the URL shortening service. The playground now features a button which brings up a shortened URL for the current playground URL including its hash. This gives you the chance to share your code snippets easily without the need to bother with the very long URL containing the playground example code.

The next task is to support gist.github.com. We already started the implementation and hope to have it ready for the next weekly.

Bugs

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

Generator

Configuration

An new and experimental configuration feature has been added: the use of a user-specific profile directory. Currently, the generator will look for a file <user-home-directory>/.qooxdoo/generator.json, "user-home-directory" being the platform-specific path to the current user's home directory (ie. what Python's os.path.expanduser("~") evaluates to). On *ix platforms, this is equivalent to the shell's "~" directory, on Windows platforms something of the form C:\Documents and Settings\<username>.

If the generator.json file is present, it will be automatically included as the first include file in the current configuration file. This way, you can inject generator settings into all jobs you run in various applications. The syntax of the generator.json file is that of a normal qooxdoo configuration file. You can e.g. enable extensive logging for all source builds, or force a format:false for all build scripts.

Performance

Work has been done to improve the re-use of cache objects during build runs of the generator. For one thing, there was an inconsistency in the way syntax trees were written to the cache, so that same trees were calculated and written twice, rather than re-used. This has been fixed.

Another improvement concerns builds with variants. In general, the syntax tree and (consequently) the dependency information of a class is affected by the variant set that is to be build, so this information is stored in the cache under a key specific to the variant set. But what if a class uses only a subset of the variant keys in the current set (or doesn't use variants in its code at all, for that matter)? Then its tree and dependency information could be re-used for several variant sets where changes in the value of a variant doesn't affect the specific class. Exactly this kind of re-use has now been implemented, resulting in less cache space and less run time requirements (as e.g. only 33% of the framework classes use variants code at all).

Finally, for the calculation of image information (e.g. image sizes), cache access has been optimized, so the generated information is written less often to the cache. For applications using a lot of images (i.e. a couple of thousands), this was a hot spot, too.

All optimizations together can lead to remarkable speed gains for an initial build run (empty cache) in certain scenarios, like more than 50% for a project that creates several variants with lots of graphics.

Community

QxWT

Along with the release of qooxdoo 1.0 a new parallel project QxWT has been made available. Kudos go to Tom Schindl from BestSolution.at, who did a fantastic job of creating a GWT-wrapper for qooxdoo: QxWT exposes most of the qooxdoo-JavaScript-API to GWT-Java-developers. Just like qooxdoo is a JavaScript-only application framework (without requiring HTML, CSS or DOM knowledge), think of QxWT as a Java-only version of qooxdoo, based on the Google Web Toolkit.

There has been some more progress since the original release, and Tom posted a series of more detailed articles, #1, #2, #3. If you're heavily into Java or have been using GWT already, you should check it out.

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

Before the 1.0 release we did a survey on our mailing list about "Your favorite aspects of qooxdoo". One of the often mentioned aspects was the support by the community on the mailing list. Many of you were quite happy with it, but not everyone likes mailing lists and some people refuse to register on the list for different reasons.

So we want to test an extension of community support channels. You have certainly heard about, maybe already used Stack Overflow, one of the most popular programming Q & A sites on the web. From Wikipedia: "Stack Overflow is a website featuring questions and answers on a wide range of topics in computer programming. The website features the ability for users to ask and answer questions, and, through membership and active participation, to vote questions and answers up or down and edit questions and answers in a wiki fashion. Users of Stack Overflow can earn reputation points and “badges”".

As a possible alternative to the regular mailing list, some people might prefer to ask qooxdoo-related questions on Stack Overflow, as it might have some advantages:

• The system shows - during typing a question - already asked questions, which might have an answer to your question. This can bring you to a solution without even asking.
• Stack Overflow uses tags to categorize all questions. qooxdoo has its own tag ("qooxdoo", of course) which gives you the ability to tag your questions and additionally subscribe to a RSS-feed containing all qooxdoo-tagged questions.
• You can vote answers to show which was the most suitable answer for you. This can also help to find a solution fast.

But don't worry, we are not planing to replace the mailing list with Stack Overflow. This is just a test for a parallel usage of the two systems. If you like to continue to ask your question on the mailing list, that's just fine as it is the primary qooxdoo community support channel. But if you haven't seen Stack Overflow (or are an active user there already for non-qooxdoo questions), give it a try. It's worth looking! Let us know what your experience and preference is regarding the existing mailing list and/or Stack Overflow, and what you think about such alternative communication channels.

On behalf of the qooxdoo core team: "Happy New Year!" to everyone, welcome back in 2010.

The last year has been a very exciting and successful one for qooxdoo. Many of you already follow the project closely, for instance by reading the weekly status reports, being an active member on the mailing list or in bugzilla, providing and maintaining contributions, and in many other ways. Thanks to everyone for the ongoing support and to make it possible to ship qooxdoo 1.0 end of last year.

This major 1.0 release has been well-received and got some good press and attention. If you are a new user or returning to qooxdoo for migrating or continuing with existing apps, we hope you enjoy all the built-in features of this comprehensive and practical package. If you have questions or suggestions, let us know.

If you have some good user experience with developing qooxdoo apps, let others know as well (personal blog, twitter, etc.). Particularly the more experienced qooxdoo users are also asked to add to our own activities and keep promoting qooxdoo on various channels (real-life examples, blogs, magazines, conferences). Please get in touch with us to get some input, help or heads-up for those activities, just don't forget to let us know about it to coordinate some efforts.

We are looking forward to working with you on making 2010 a great year for qooxdoo, its wide-spread adoption and its ongoing progress.