Enjoy another weekly wrap-up:
Surely all of you have seen a typical qooxdoo splitpane already or use it in your own applications. The Demobrowser, Playground or Feed Reader that come with qooxdoo use this component as well. But in all those three applications, the handle to grab the splitter is quite small, so we already implemented some kind of distance detection. This allows to set an pixel offset and make the clickable area a bit wider than the splitter itself. But this distance detection triggered some massive calculations which lead to quite a slow cursor change.
We had a closer look and in the end managed to remove the whole distance detection and replace it with an implementation using a blocker, which can benefit from CSS for changing the cursor. So you should really see and feel a speedup in cursor handling, especially in old – therefore slow – browsers. Just give it a try in the online apps and compare the Demobrowser of trunk with the latest stable.
We also spent some time on the mouse wheel handling and its intrinsic speed, which is kind of a mess in browsers. When receiving a mouse wheel event, it comes with a so-called “delta” information, which is then used in the qooxdoo scrolling. The problem here is that every browser returns a different number depending on such conditions as: acceleration enabled or not, operating system and so on. It goes as far as that even the same browser returns different numbers on two different systems, e.g. Chrome. For a long time we had a fix for that using browser detection and accounting for the version-specific factors. But over time this detection was getting bigger and bigger and grew with (almost) every new browser release. So we took some time this week and checked if its not possible to do some clever calculation which replaces all this browser sniffing code.
Finally, we ended up with a solution that seems to work for every browser / OS / mouse combination we were able to test. But as you can guess, there certainly may be a lot of other combinations out there. So we rely on your feedback on how mouse wheel scrolling feels for you using your individual setup. Just take a look at our devel apps, pick one, for example the demobrowser, and check the scrolling behavior when above the tree on the left (make sure you expanded many folders to have a large enough tree to scroll). We really like to hear back from you on that.
While checking for IE9 beta support we found some minor issues in our text selection implementation. The main issue was that the implementation was distributed over too many classes. Thus we refactored the implementation to keep it as maintainable as possible.
In the past a few times people asked about how to embed map solutions into a qooxdoo app. We now added a new demo, which demonstrates exactly that for Google Maps and Yahoo Maps:
When calculating class dependencies the generator so far printed a “.” to the console, to show its progress. To make this more informative, a “*” (asterisk) will now be printed for a freshly analyzed class, and the usual “.” (dot) if the dependency information could be retrieved from the cache.
Speaking of dependency analysis. This has been augmented to follow dependencies of method calls outside function definitions. An initial implementation is in place, but will be overhauled, particularly with respect to cache handling. The aim is to have a dedicated cache object for each class that holds dependency information on a per-attribute level. This allows for caching of class-local information which can easily be invalidated, and has then to be exploited in a recursive algorithm that calculates transient results for the current build run.
For a complete list of tasks accomplished during the last working week, use this bugzilla query.
C U again next week!