Nokia spreads the love; KHTML gets love; GNOME love on #kde-devel

as you may have already heard, Nokia has adopted KHTML as the webbrowser engine for some of their product lines. the head of marketing and strategy for the series 60 browser just emailed kfm-devel with a great introductory email in which he made first contact and introduced their web browser team to the KHTML team.

and why did they pick KHTML?

The high performance, low memory consumption and small code footprint of KHTML and KJS make these components ideal for resource-constrained mobile devices. Clean architecture and good design create a good base for future development of mobile features. In addition, Web compliance was another important criteria for us. Congratulations to the KDE Konqueror developer team for building such a great browser.

Big thanks at this point also go to the Apple Safari team that has tremendously improved KHTML and KJS in many areas, in particular in Web compliance and performance. WebCore and JavaScriptCore also offer a cleaner separation to the underlying operating system. For these reasons we at Nokia chose WebCore and JavaScriptCore as the code base for our Series 60 mobile browser.

Our plan is that the new Series 60 mobile browser will be available as a standard Series 60 application during the first half of 2006.

We at Nokia are excited to use WebCore/KHTML and JavaScriptCore/KJS for our future Series 60 mobile browser. I hope that we can start a dialogue with your community and the Apple Safari team on how to "mobilize" WebCore/KHTML and JavaScriptCore/KJS to create the best Web browser based on open-source components for mobile devices.

that's brilliant. i can only assuem that the KHTML.info portal is going to play an imoprtant part in this cooperation.

this kind of development community around KHTML is exactly what it needs. not only because the KDE KHTML hackers who have done an amazing job over the years could use more hands, but because as groups like Nokia and Apple pick it up more web developers will test their apps against it. that is probably the #1 challenge for a web browser: getting people, especially those writing enterprise applications, to test against it. (google, are you listening? =)

given the resource friendliness, web compliance and high portability of KHTML i can only wonder who might be the next to adopt it. if this KHTML adoption trend continues, we may be seeing the rise of a new defacto engine in the custom browser industry. this is just one more way to ensure that Internet Explorer's counterproductive dominance of the web browsing market erodes away to more sane levels.

speaking of google, don't forget that the deadline for prosals for the summer of code draws nigh: the 14th! so be sure to polish up and send in your KDE proposals before it's too late

switching gears a bit more, a couple of GNOME hackers started hanging out in #kde-devel on the freenode.net IRC network. it's been enjoyable to discuss topics ranging from packaging, build systems, system trays, cairo and gstreamer with them and to have them join in on our conversations as well. it's been a nice insight into their perspectives on things and the good natured quality of the discussion even when we see differently on matters has been refreshing.

as we all work in the "open source desktop" space and target similar platforms it really makes sense to engage in these cultural exchanges. it certainly increases the feeling of greater community and opens the door for greater cooperation in areas that make sense.