Portal - A Low-level DOM Demo

With Portal a new application has entered the qooxdoo trunk. This small demo shows some cool features of the new low-level layer, which will be a subset of the upcoming qooxdoo 0.8 release. This layer does not use any of the high-level qooxdoo widgets. Instead, it is a lightweight, DOM-oriented solution that provides an alternative to other popular libraries like Prototype or jQuery. Of course, it is fully cross-browser and allows for very sophisticated coding by offering all the well-known OO features of qooxdoo. A comprehensive API documentation - even for such a low-level app - can easily be generated. Be sure to check it out!

Eclipse Ganymed

Probably you have already heard about the release of Eclipse 3.4 (called "Ganymed"), which was made available about two days ago. They stick to an annual release cycle, so the new version includes a lot of fixes and improvements. If you are an Eclipse guy, you probably have the IDE (which is only one but the most prominent part of the entire Eclipse ecosystem) installed and running already. If not, this is a good opportunity to give the Eclipse IDE a try. While it may not be perfect (well, what editor or IDE is?), it is an excellent solution. Best of it, it's open source! Of course, we had to celebrate the new Ganymed release at one of the DemoCamp events.

Generator

A major part of this past week went into carving out the Config and Job classes that are responsible for providing the information from the config files to the rest of the Generator. They handle all the including of configs and expanding of jobs, returning a fully expanded job that has all the information and is ready to be run. The code is now clearer, better organized and reflects much better the "theory" behind it. I really started loving it.

On the feature level, these are the news:

• Name space-less includes
  As mentioned in a previous post, jobs from external configs are added to the local job list (they are "lifted"). Previously, these imported jobs were renamed to include a prefix that acted as some kind of name space, and thus could prevent name clashes. This has been disabled by default, so external jobs will now be added to the list of runnable jobs with their original names. This puts the burden of avoiding name clashes on the importing config, but now you can run e.g. a 'source' job without even defining one.
  On the other hand, you can still define optional name spaces for the job names from those imports. To support this, the syntax for the top-level include key has been changed; it is now an array holding a map for each imported external config. The mandatory entry in those maps is a 'path' key that points to the file location. If you wish to import the jobs namespaced, add the optional 'as' key in the respective map. The format for referencing those jobs slightly shifted to use '::' as a name space separator (rather than '/'), so if you used

    "include" : [ { "path" : "../my/other/config.json", "as" : "otherConfig" }  ]

  you could refer to a job from that config e.g. in an 'extend' section like this

  "extend" : [ "otherConfig::<jobname>" ]

  and external jobs will also be listed in this form on the command line with '?' as the jobs argument.

• 'export' lists
  Configs can now list the jobs they want to get exported when another config includes it. This is just a selection from the entire list of this config's job keys, and helps to limit name space pollution in the importing config. The syntax is a straight-forward top-level entry like this:

  "export" : [ "jobA", "jobB", "jobC" ]

• Top-level macros
  You can now add a 'let' section on the top-level. Macros defined therein will be added to every job automatically and without explicit reference, so be aware of side effects. If a job already defines a 'let' map, the global map will be merged into the local in the usual way, only adding new keys and their values. This is done before any extend is resolved, so keys from the global let take precedence over all jobs from the extend section. - The rational behind it is that most standard configs can be reduced to just including the 'application.json' default config, and adding some macros. The experimental 'defaults' job that had similar qualities is gone.

The full documentation for all these config settings is available here.

If you look at the current config.json files of our standard applications (Apiviewer, Feedreader, etc.) they are on various levels of making use of configuration features. Some rely on the settings from the central application.json, others make their settings explicit, doing it more "by hand". Expect to see more features moving into these config files while the config file feature set stabilizes.

Widgets

Subcontrol support

Subwidgeting and child widget handling was a major theme this week. Subcontrol support was added to a lot more widgets thanks to Jonathan's and Sebastian's work. This new widget managment is used for lazy creation and automatic disposal of widgets, but also for the new appearance theme features. Every subcontrol is seen as a child in the appearance as well. The previously flat structure flag keys became somewhat structured resembling XPath expressions, e.g. "spinner-up-button" became "spinner/upbutton". Here are some more facts:

• These widgets now use child controls:
  SplitPane, ComboBox, SelectBox, Spinner, Toolbar, TabView
• These widgets use remote children handling now:
  ComboBox, SelectBox, Toolbar
• ComboBox and SelectBox have gotten a nice "Modern" theme.
• All appearance names have been consolidated (e.g. it is now "textfield" instead of "text-field")

Spinner

The Spinner is completely themable with all internal children by changing the (public) appearance property. All internal widgets get updated automatically. The minimum/maximum handling of the Spinner was improved. The new version does not accept a value anymore which is out of the currently configured range. The old version did some implicit normalization which is not regarded as a good idea anymore.

ScrollArea

Some remaining issues in the ScrollArea were fixed. The scroll-into-view feature is now available on every widget and is automatically scheduled using the queue managment when the widget or the child to scroll is not rendered at the moment. Gecko and Safari lost the current scroll position when a DOM node gets invisible or temporarly removed. This is an issue for us, especially in the new Selectbox and Combobox widgets because they should re-open the popup in the state they were closed. The scroll area now takes care of these issues and recovers the last known state on every open of the popup.

Miscellaneous

The Element event handler was fixed. After some rework of the event system some weeks ago this handler got a few issues. Events like "scroll" or "load" etc. should now work again.

The Selectbox and Combobox widgets have gotten another bunch of love. They are now regarded as nearly feature complete and appear to be quite solid already.

The Splitpane widget has got a lot of fixes to improve the rendering in some edge cases. The issue where the splitter was moved some pixels away from the cursor on the mouse up event was fixed as well. There are no known rendering issues anymore in the splitpane. Please try it yourself.

Global cursor support was re-introduced in the trunk. As this was a performance issue in IE all the time and never worked 100% OK, the feature was removed in IE. In all other browsers the feature is quite cool, especially for scenarios like resizing or drag&drop where the original target is left during a mouse move sequence. You can see the feature yourself in the Splitpane demo.

Some minor issues with the event handling where fixed. The last weeks version had issues to remove captured listeners. This is quite critical in some areas and good to know that it should now work correctly.

That's for this week's report - have a nice weekend!

Welcome to a new weekly status report.

Siarhei visiting

This week we had Siarhei visiting the qooxdoo framework team at 1&1 in Karlsruhe. Before, we knew each another just from the mailing list and individual emails, so it was a great experience to meet in person. We had a lot of fun hanging out together, watching games of the Euro 2008 Soccer Championship. Of course, we also talked a lot about qooxdoo, QxTransformer and a lot of interesting technical stuff, be it related to qooxdoo or more general. Siarhei (pronounced like "Sergey" as we learned) is from Minsk/Belarus and was on a business trip at a local customer. If you also happen to be in Germany and possibly close to Karlsruhe, let us know, we'd be happy to invite you over to meet the team.

Generator

Generation of different files according to chosen variants were added, and a new section on packages has been added to the config manual. The generator.py command line was simplified through making the -c switch optional and defaulting to config.json, and removing the -j switch and making the job list into an argument. Please adapt your build invocations.

String Optimizer

The string optimizer in 0.8 now creates a closure around each class and defines scoped variables. In earlier version an global array (for all classes) was used which helps to reduce the cost of strings in IE dramatically, but still means that you have an additional lookup to an array index. The inspiration came from GWT. They seem to optimize strings in the same way. And from now on qooxdoo can do the same for every qooxdoo 0.8 application.

Fun with IE stack size exceeded

We ran into an issue this week while working with list widgets where IE would bomb with a stack-size-exceeded message. Since it is not trivial to find the code that might cause this stack overflow, we used qooxdoo's AOP features to track down the issue. To that end a Tracer class was defined that would record stack depth and store the highest reached stack depth and the corresponding stack. (For your own aspect classes you can find a template here).

Finally it was related to some redirection of the focus in the original focus event. The implementation for IE used a native method to make elements active, this was one cause of the issue. Finally I also cleaned up a lot of the existing code. It is somewhat complex stuff. The focus handling has nearly completely different implementation for each supported browser. It looks quite good now. The support for Opera and Safari was improved as well and seems to be quite solid now as well. You might want to have a look yourself into the various examples.

Scrolling TabView

This is somewhat like a quite old issue. If a TabView in 0.8 has too many tabs to show them together you automatically get two scroll buttons to slide the tabs to the desired side. This is never a good choice from the usability point of view, but still a good default behavior for any toolkit.

Legacy_0_7_x

Fixing memory leaks in various widgets - thanks for the submissions.

C U next week.

Another week towards the qooxdoo 0.8 release. We're making constant progress so you should get started to become excited (in case you aren't yet).

qooxdoo 0.8

SplitPane

Porting the SplitPane widget is almost done. The new version is much leaner and nicer using only three classes instead of six since, much of the styling can be done using the appearance system and decorators. Furthermore, the new API is much easier to learn: Only two accessor methods are used to access the widgets inside the SplitPane instead of having eight different methods depending on the SplitPane's orientation. Adding widgets is more convenient, too: a SplitPane is filled from top to bottom or left to right, respectively.

The size-handling was improved as well. Instead of passing the sizes (or flex values) to the constructor, static sizes are set on the widget itself before insertion; flex values on the other hand are layout properties which are set when adding a widget to the SplitPane.

See a first SplitPane example. Please note, it is still work in progress so some features (such as live resizing) may not be working properly just yet.

Widget Core

A possibility for compound widgets was added to redirect the properties "padding", "font" and "textColor" to an internal sub widget. For example setting the padding property on a window instance will now redirect to the padding of the window pane instead and thus no longer break the layout.

Window

Talking of windows, they can now also be centered easily. Another demo has been added to demonstrate how a custom web browser could be implemented in a qooxdoo window (Oooh, don't you love the 0.8 theming...).

Documentation

First steps of re-organizing the wiki to account for the qooxdoo 0.8 documentation have been made. Also a first draft of a fundamental GUI overview article has been created. This article will get some more love and polishing within the next few days. In case you haven't seen it, also check out the blog post about the layered architecture of the upcoming GUI toolkit which. As its covers "From DOM to Widgets", shouldn't we have called that "From Dusk till Dawn" instead?

Runtime switching

In 0.7 there are two features that allow for switching both locale and theme at runtime. While these are nice features per se, they don't come without a cost in terms of application performance and code complexity. As qooxdoo further matures we think it's time to drop such features that may not be too relevant in real-life scenarios. In order to get some feedback from the community we started a thread on the mailing list. If you have an opinion or experience, please share them with us.

Generator

The tool area of qooxdoo saw some SVN re-org in the 'ecmascript' module, to prepare for further modularization of the compiler.

In the realm of configuration, "job lifting" has been implemented whereby imported jobs are added to the jobs map of the importing config, rather than under a common name space entry. That means that imported jobs can now be listed with '-j ?' or invoked with '-j <jobname>' from the command line of the generator. Still their names are prefixed with a namespace-like string on import, to avoid name clashes. But we plan to change this so jobs will be imported under their original name, putting the demand of resolving name conflicts unto the importing config. But this way we can offer a 'source' job on the top-level which is actually imported. Together with global definitions which are recognized without being explicitly referenced (currently, there is an experimental "defaults" job), this all adds to the ultimate goal to have config files on the application level that have only to specify a minimal amount of information for all the standard jobs 'source', 'build', 'api', ... to work, as long as they have no special requirements. In a future step, the list of jobs to be imported can be specified by the exporting config, to limit the number of symbols (think: jobs) that are added to the importing config's name space.

Abobe on AIR Tour

Adobe did a great job offering a one day conference on Adobe AIR with technical sessions, showcases and discussion. It was part of their on AIR Tour Europe 2008. In order to make this event even more attractive they made sure to "provide the beer, coffee, food, XBoxes, schwag, knowledge, venue and bits". Of course, we didn't want to miss out and went to Munich to socialize with some of the Adobe developer folk, also meeting again some people we knew from previous conferences. As expected it was a fine event and we particularly enjoyed talking to Kevin Hoyt (Adobe) and Wolfram Kriesing (Dojo).

As qooxdoo has been one of the first adopters of Adobe AIR (dating back to July 2007!), it somewhat reminded us to re-introduce AIR support into the framework and also to extend it to include features of the latest AIR versions. It may not be all too soon due to our focus on qooxdoo 0.8, but you can bet on some smart AIR support in the future.

Ultimate Party

As the perfect end of the working week and start into the weekend we now leave for the ultimate 1&1 summer-time party. There should be roughly 2.500 fellow coworkers of 1&1 having a great time this evening. Wanna join a great company? Check out their international job offers as well as the qooxdoo-specific job offers. Hurry up, next big party is right before Xmas.

Cheers and have a nice weekend!

For qooxdoo 0.8 we have introduced a layered architecture from low-level DOM to high-level widget system. For instance, we extracted all lower-level implementation details out of the widget system and moved them into a new layer (that could also be used independently). Interestingly, this was already mentioned about a year ago and I thought it would be a good idea to refresh the information from the last report.

The layers of qooxdoo in 0.8:

• qx.dom contains generic DOM methods. This includes basic stuff like information about the different node types, positioned inserts of nodes, a huge range of traversal functions.
• qx.xml contains specific features to work with XML documents. Features include selectNode, createDocument and string escape routines specific to XML.
• qx.bom contains all stuff which is specific to the so-called "browser object model". Included are features to control specific attributes of HTML elements e.g. utilities to work with styles, class names, etc. It also connects elements to the event system. There are many more things: Computing locations of arbitrary elements in relation to the document, scrolling any visible element into the viewport, inserting Flash movies, working with the browser history and creating pseudo bookmarkable pages, dealing with XMLHttp requests in a unified fashion, detecting the client and a number of the most common plugins, creating enhanced shrinkable labels with ellipsis symbol etc. All these features work in all four supported browsers equally well.
• qx.html is the new high-level DOM manipulation API. It is mainly thought for the managed creation of HTML nodes. It wraps most of the features of qx.bom and offers them in the well-known qooxdoo OO style programming fashion. With this API you work with an instance for every DOM node you like to create. This may seem very expensive at first glance, and in fact it isn't without cost, but in practice it performs quite well. And best of all: it automatically gets a lot of stuff right which otherwise had to be done over and over again in an application or the widget system itself. Yes, the widget system uses this API to work with the DOM. The major feature of this API is the managed creation and insertion of DOM nodes. It works perfectly for multi-pane views (e.g. Tab Views) and makes generation of whole areas as lazy as possible without any additional work required. Compared to qx.bom these features do make most sense when creating a huge chunk of HTML. For simple modification of existing nodes or creation of a handful of nodes qx.bom is the better choice.
• qx.ui contains the GUI toolkit of qooxdoo 0.8. Here you can find all things comparable to other (native) toolkits. This means for instance: real layout managers, improved event and focus handling, decorators for all types of styles, full-blown theming capabilities without the need to use HTML or CSS.

Hope this is a useful overview. Feed free to ask questions, your feedback is appreciated. This blog post will become part of the forthcoming documentation of 0.8.

After successfully participating in conferences (webinale, Dynamic Languages World), we are getting used to our "regular" development work again...

Community

Slides

In case you haven't seen the presentations yet, check out the slides that have been uploaded to the SlideShare service, using "qooxdoo" as a tag.

Bugzilla

Continuing with development of qooxdoo 0.8 we took the opportunity for some overdue spring-cleaning of our issue tracking system. It's work in progress, but we have already started to use bugzilla more intensively in order to make the development process more effective and also more transparent. Todo items have been moved over to bugzilla. Within bugzilla, 'application' and 'tool', which were previously in the 'product' category, are now subsumed under the 'framework' product, and existing bugs have been moved accordingly. This helps e.g. to have consistent version and target attributes for all framework related stuff. Once the dust has settled there will certainly be more info on the blog.

Real-life examples

If you are feeling happy having created a cool qooxdoo application, it would be great to share this info with the community. Please add your app to the real-life examples. Besides a short description, you might want to provide links to the online version of your app, or screenshots if it is an intranet and/or non-public solution.

Framework

Events

Searching for the correct qooxdoo event handler has been heavily optimized. "addListener" calls are much faster now (Bug #895). Methods firing an event like "fireEvent" or "dispatchEvent" now return false if the event was canceled using "preventDefault". "addChild" and "removeChild" events are now fired on "qx.ui.container.Composite" widgets each time a sub-widget is added or removed.

Window widget

Lots of events were implemented (close, maximize, minimize, restore, beforeClose, beforeMaximize, beforeMinimize, beforeRestore). The actions which correspond to these events can be canceled by calling "preventDefault" on the event object. The new sub-widget system is being used for Window, the status bar is created lazily. Also, the decoration has been improved.

Other widget stuff

• There is a new SelectBox widget. The SelectBox is a non editable version of the ComboBox.
• The SplitPane is in the process of being ported to the 0.8 widget system, with a completely new layouter for this widget. The widget itself is still missing, but the underlying layout looks quite good so far.
• Completed API documentation of ScrollArea. Cleaned up and improved more implementation blocks. Support for "scrollIntoView" was refactored to use newly available methods.
• Support for scrolling of "not-yet-rendered" widgets. This also includes "scrollIntoView" support. With the new version it is possible to select list items during the main() method. Items selected this way are automatically scrolled into the viewport.
• Initial focus support is back in SVN. It is now possible to focus widgets during the main() method and make them focused on initial display of the application.
• Introduced support for shrinking to Atom (basis of Buttons, Tabs, ...). The Atom now shows an ellipsis symbol when the label is not completely visible.
• The selection managed by a selection manager now gets notified each time a selectable item is added or removed from the managed widget. Improved selection system to fix issues when the selection is changed programmatically. Previously, the lead or anchor items were not updated correctly in some cases.

Miscellaneous

• The user data support has been moved into qx.core.Object. Now it is possible to add any type of runtime data to any instance of qx.core.Object.
• Minor improvements to the aspect and profiling support have been made. Fixed issue where class reference where wrapped by aspect orientation support.

Tools

Generator

There was some clean-up going on in the generator and config file area. This included some renaming and introducing of config keys, breaking existing configs. I hope everybody working against the trunk version could gather enough information from the commit messages to get their build process going again.

The generation of resource information for the build version has been decoupled from the actual resource copying, so you can run a 'compile-dist' job without the need of a previous 'copy-resources' job, and still get a meaningful result. Of course, you still need to run both jobs at some time to get a working build version in the end :). We also started to tag mandatory keys in the documentation.

Contrib

Crypto

Greetings, NSA. Given the comprehensiveness of qooxdoo, it's time to complete the framework with some JavaScript implementations typical for cryptography and encoding/decoding in general. It has popped up in the community before, but as Bill brought this up again recently, let's get this task done. All interested people are welcome to collaborate in the new qooxdoo-contrib project Crypto.