After visiting a really nice collection of exhibit gardens, I decided to make an application to see how different plants are related by making a phylogentic tree generating webpage.

For many groups of species, the familiar relationships have been examined very well, but for the combination of arbitrary species, you have to rely on taxonomic data for now. A convenient resource for getting at this data is NCBI taxonomy (ftp). This data unfortunately has no timeline distance between the branch points, but it's nice enough for starters.

For implementing the website I do not want to rely on server-side scripts. So the page will have to process the data via javascript. The current development version has a 12 Mb JSON file. This is the minimal amount of data for working on a tree with all species listed by NCBI.

And this is where the problems start. Because javascript is not the most efficient language for doing this. And the current version of the page is very heavy for all browsers. In fact, Firefox 3 is the only browser that can load the page in a decent amount of time (8 seconds on a 1.1 Ghz machine). Konqueror 3 keeps asking me if I really want to continue running the script. Konqueror 4 crashes. Opera 9.5 is less than least half as fast as Firefox. So perhaps this page can be used as a nice torture test for javascript developers.

To use the page, type latin species names in the text box and press enter. This way you can build up a tree. It's not user friendly at all. I'm still making a more nicer version with links and pictures.

Kross, the scripting framework, is one of the pillars new with KDE4. While the project started already a while back in 2004 it enveloped over the time to a rather big codebase. During the KDE4-process one of the main-goals was to decrease the codebase what can be even more difficult then writting new code.

Once in a while we had an interesting pool about the Preferred Scripting Language where the result showed something of a concensus that Python and Ruby are the primary preferred scripting languages (from within those small list of possibilities the pool offered).

Well I got in a few good nights of hacking on KJSEmbed and am getting back up to speed again. Last night I fixed a big problem rich was having in the scribble demo.

I finally got some time to spend on KDE last weekend, so on Sunday I started working on a new binding generator for KJSEmbed on Qt 4. In the KDE 3 version I used Doxygen to generate XML output then processed that with XSLT (using xsltproc) to produce the C++ code for the bindings. Unfortunately this provded to be a bit too inflexible, and difficult for other developers (who weren't familiar with XSLT) to work on. The new code uses KJSEmbed's DOM bindings to process the Doxygen output and seems to be a lot easier to work with - [mX] was making improvements within a few hours of the first commits. This also means we might be able to make the bindings self-hosted in KDE 4 which would be nice.

When I get a bit more time (this weekend hopefully!) I plan to try to get this code pushed a bit further - thanks to [mX] it can already mostly do value types, just objects and scalars to go!

Oh man, these last few weeks have been rough. I got a new toy, but that is an entirely different blog all together. So here is the lowdown on what I got working with KSJEmbed in the last few weeks:

So over the last few weeks I have started work on the new KJSEmbed that will be in KDE 4. In a change of heart that is an entirely different blog all together I have decided that I will push to have KJSEmbed in the core of KDE 4.

I've started looking into porting KJSEmbed to Qt 4. To begin with, I've recreated most of the Q_CLASSINFO demo I posted recently using the Qt 4 equivalents. Listing the slots of an object is even easier than before, as is finding a marker interface:

So i was trying to figure out how to copy songs from my favorite Juk play lists onto my mp3 player most efficiently. So I hit up wheels about Juk's dcop interface. One word "Wow".