Nokia Engineers on KHTML, Collaboration and aKademy

So, you have KDE on your desktop and laptop systems, you've heard
that Apple uses KDE components for its web browser Safari and you've
tried Konq/Embedded on your handheld. But did you know that KDE could
soon be making its way into your mobile phone? At aKademy in August
David Carson and Deepika Chauhan from Nokia presented the work they've
done in integrating KDE components into the latest version of the
company's mobile phone software. I recently caught up with them to ask about the technical side of their work, why they chose KDE components and their experiences of aKademy.

Can you describe briefly what you're working on within

We are working on the Series 60 Browser application for the S60 platform.
The Series 60 Platform is the software platform that runs Series 60 devices, which are also called smart phones. The Series 60 Platform consists of a user interface for interacting with the device's data and software, and programs (Series 60 applications) that provide advanced phone functions such as messaging, the calendar, browsing, etc. The
Series 60 Platform runs on top of the open Symbian OS operating system.
In addition to existing applications, users can also install additional

What technical challenges do you face in that work?

Mobile devices are constrained by ROM, RAM, network latency and
bandwidth, display, input mode, and less powerful CPU as compared to
desktop world. We need to make some changes to take into account these
constraints. The code execution behaviors which are correct in the
desktop world do not always work well on mobile device.

To give an example, in browsers Javascript needs to be executed at
the point that it is found in the markup, resulting in blocking the
parser. External Javascript files take a much longer time to arrive at
the client over GPRS. In the worst case scenario, the consecutive
multiple external javascript references cause the requests to go out
serially. Similar problems are encountered in CSS processing since
rendering blocks on external CSS. We do not encounter these problems
when the Javascript and CSS are inline.

What parts of KDE are you using to help you achieve your

We are using WebCore and JavaScriptCore components from Apple's Safari
Browser which are based on KHTML and KJS components respectively that
were developed by the KDE community.

Why did you choose KDE over the competition?

We have been developing a proprietary browser for Series 60. We found
that we have been focusing a lot of resources on dealing with issues
like rendering and script execution - issues that have already been
dealt with by open-source components. We decided that since browsing is
a complex technology, we should not re-invent the wheel. We started
investigating the available open-source solutions and decided to go with
a KDE-based solution for primarily 3 reasons:

  1. Series 60 devices are constrained by ROM/RAM. WebCore/KHTML and
    JavaScriptCore/KJS provide rendering engines that use very small RAM/ROM
    footprint. That was really a clincher for us.
  2. WebCore/KHTML and JavaScriptCore/KJS provide a very clean
    architecture enabling easy ramp up of resources.
  3. WebCore/KHTML and JavaScriptCore/KJS are very fast. The startup time
    and general performance of the browser is quite good.

How do you see the relationship between the KDE project and your
team at Nokia developing?

We would like to find a model where we can collaborate with the KDE
community focused towards browsing related solutions.

More generally, where do you think mobile technology is going in
the near future, and what part will open source software like KDE

With the advent of faster networks and more capable mobile devices we
expect to see a lot of development in the mobile software area. We hope
that in the future the KDE community will be interested to look beyond
desktop software and considers taking on projects in the mobile software
space. We see Nokia's new open source browser as a good project to
spark the open source community's interest in mobile software

What was your experience of aKademy?

We had a great time at aKademy, and we got much more out of it than we
ever anticipated. We came to aKademy since we wanted to thank the KDE
community for the great components created by them that form the basis
of the future Series 60 browser, meet some of the contributors in
person, and share with the community our experiences of building a
browser around WebCore/KHTML and JavascriptCore/KJS. The conference gave
us a better understanding of the working model of KDE. We hope that we
can work together with KDE on the mobile browser. We have observed a
lot of excitement among developers in contributing to the mobile
applications and we hope the community can bring their innovations to the
mobile platform.

Many thanks to Deepika and David for taking the time to talk to me.


"To give an example, in browsers Javascript needs to be executed at the point that it is found in the markup, resulting in blocking the parser. External Javascript files take a much longer time to arrive at the client over GPRS."

Why can't web pages be preprocessed by the wireless provider, before being sent to the phone? E.g. make all JavaScipt and CSS inline (and maybe even execute some of the JS), remove tags that won't be displayed anyway (Flash, Java, some formatting), to make HTML simpler and smaller?

By Dima Ryazanov at Sun, 2005/10/16 - 5:00am

You would still need a powerful rendering engine on the phone; otherwise you would have no chance of rendering complex webpages anything like how they appear on your computer screen (which is the goal). These phones have the processing power to run a real web browser, all that Nokia really needs to do is port one. So they are.

By Spy Hunter at Sun, 2005/10/16 - 5:00am

If the code is changed at the provider it is changed for all browsers. If I connect my notebook to the net via cellphone and use a normal desktop-browser like Konqueror I wouldn't really like that...

By Ascay at Mon, 2005/10/17 - 5:00am

If it is implemented sensibly it would be done using a proxy server - and you would have the choice of using the proxy or not.

By David Dorward at Mon, 2005/10/17 - 5:00am

I could see it being quite sensible for one to simply inline all the css/javascript. Which ideally wouldn't change the rendering. (I can think of one situation where it might off the top of my head, but I think that can be handled inline.)

By James L at Mon, 2005/10/17 - 5:00am

That seems like a really good idea to me.

Perhaps you should implement this as a product :)

By a. p. non at Mon, 2005/10/17 - 5:00am

Your dream already exists :)

My company has created a product called PocketSurfer.

By JC at Mon, 2005/10/17 - 5:00am

Opera already does this with its Opera Mini application suite (http://www.opera.com/products/mobile/operamini/). It requires a concerted effort by both manufacturers and phone providers though, and there's still severe levels of rivalry in the business that make it hard to roll out something like that.

By Bryan Feeney at Mon, 2005/10/17 - 5:00am

"Why can't web pages be preprocessed by the wireless provider, before being sent to the phone?"

Do you really want the WAP fiasco all over again? I prefer my network dumb and trasparent and the smarts in the endpoint, thank you.

By Oren T at Mon, 2005/10/17 - 5:00am

No, WAP has nothing to do with his idea. WAP wasn't about the server. WAP just brought a new markup language (WML) more suitable for mobile phones than HTML.

WAP wasn't succefull for two reasons:
- few websites published WAP versions (I don't blame webmasters, it just wasn't an easy task);
- the user needed to specify a different URL than he would for the regular version.

By blacksheep at Tue, 2005/10/18 - 5:00am

This is basically how WAP works.

By Alex at Mon, 2005/10/17 - 5:00am

This is what we do in my company. The product is called PocketSurfer
We process html before sending to the wireless device.


Because that would break browser caching on the phone. For example, a cnn.com's HTML content probably changes more often than its CSS or JavaScript. If the CSS and JavaScript are in separate files from the HTML, the browser can cache them.

By cpeterso at Mon, 2005/10/17 - 5:00am

Nice to see Nokia use Webcore, but to say that "KDE could soon be making its way into your mobile phone" is a little presumptious, insn't it? They're only using the de-kde'efied khtml from Apple... There's even a Gtk-version, developed by Nokia: http://gtk-webcore.sourceforge.net/

By Foo at Sun, 2005/10/16 - 5:00am

khtml is a KDE technology, ported or not. Also khtml had few as possible dependencies from the very beginning which makes it easy to port. What is presumptious about being a little proud that a KDE technology is getting widely used outside KDE itself after all those time naysayers said KDE would only reinvent and isolate?

By ac at Mon, 2005/10/17 - 5:00am

yep and the windowing system they use on their linux tablet is totally gnomish or at least gtk based, looks cool though http://www.maemo.org/screenshots.html

By patcito at Mon, 2005/10/17 - 5:00am

this type of open palmtop OS Nokia is building is more than a bit gnomish, yet they needed a leaner HTML/JS render so they came out on Apple's WebCore (based on KHTML/KJS)...

They ported it to GTK:

Nokia allready proted KHTML/JS away from a lot of Qt dependencies.

So the bottom line?
If this device is as open as it looks, it will run several mini distro's...
Then maybe one will be more KDE related.

Yet apps delivered for the default platform will probebly be GTKish.

But this is a guess...

It looks like a very interesting platform though.

My .02EUR
Cies Breijs.

By Cies Breijs at Mon, 2005/10/17 - 5:00am

From what I've seen, you're talking about two different things.
The linux tablet uses a gtk interface indeed, but the browser is a customized version of Opera.
The device on which will run this KHTML-derived engine will be Symbian based.

So two very different things.

By Anonymous at Mon, 2005/10/17 - 5:00am

Indeed, thanks for pointing out...

The WebCore port to GTK was originally done as a feasability study by Nokia for the InternetTablet770. The 770 will run Maemo.org (linux+gtk).

The Nokia Series60 will not run Linux bus symbian and will have neither Qt nor GTK, but will run WebCore by default.



Very nice to see KHTML is now widely used. Btw, what about KHTML2 & KSVG2? What's the status of them now? Are we going to have KHTML2 & KSVG2 in KDE4? And will next generation of Webcore be based on KHTML2?

By fyanardi at Mon, 2005/10/17 - 5:00am

afaik the answers are "working on it"; "getting in shape"; "yes"; "most likely".

By superstoned at Mon, 2005/10/17 - 5:00am

Wow, great to hear that! Thanks to all KHTML developers!


What would be great is XUL support. Then you could write great webapps to use in KDE.

By JJK at Tue, 2005/10/18 - 5:00am

or just use firefox and save you the hassle.

By lynxy at Tue, 2005/10/18 - 5:00am

why use firefox, if konqueror is there? it works much better with other KDE apps, is faster, and looks better...

By superstoned at Tue, 2005/10/18 - 5:00am

There's also no reason at all you couldn't use XUL in Konqueror.

By segedunum at Tue, 2005/10/18 - 5:00am

Wow, Nokia is making great steps in the open source world. I like the platform, how easy is to develop applications (in java or c++) and the fact that it now supports os components (even when they are so customized for their devices) can be a new boost for our community (marketing that spread the kde/gtk/linux name around the world, and programming skill/technology that can improve many projects).

But one thing really lacks, and I don't understand why... there is no way (other than hack with wine) to develop nokia/symbian applications using nokia tools.

No matter if you use java, c# or c++, series 40 and 60 sdk can be used only on windows. There is support for eclipse in the latest series 60 developers's suit, but it only works on windows...

They even provide you with a version of gcc, and java libraries only on windows...

By Mario at Tue, 2005/10/18 - 5:00am

There is a site for getting a subset of the S60 SDK functionality going on Linux:


It's a pain though that the emulator doesn't work on Linux, and there are a bunch of other small tools that don't work.

If you choose to use Series 60 python though, there are quite a lot of Linux/Unix tools that make it easier.

By taj at Thu, 2005/10/20 - 5:00am


Thanks for the link, I'll give it a try.

As a side note, I found a good alternative for java (it's java only, but with Python and Java and the link you give we are pretty well covered):


I need to check it out, but it seems that this library takes care of all the aspect related to graphics in j2me products, it works in midp 1.0 and cdlc 1.0 adding support for midp 2.0 to old devices, it can be customized for specific platforms, but can be used with virtually the same results on the sun wireless toolkit (so we don't need nokia/motorola/what else anymore for java programming under linux).

Having an emulator at hand for testing is a good think, but this way one can test the application on an emulator on windows just before the release.

Thank you again for the reply,

By Mario at Thu, 2005/10/20 - 5:00am