Minimal kdelibs on embedded platforms

[Inge Wallin]

As some of you may know, KO GmbH, the company I work for, has helped Nokia 
port KOffice to Maemo and their new telephone n900.  I think this is only the 
first example of where KDE applications and maybe also (parts of) the desktop 
will be used in embedded environments with other constraints than the normal 
desktop.

One of the problems we have encountered was memory consumption and flash disk 
space. Right now, the subset of 6 libraries from kdelibs we are using have a 
footprint of a little over 10 MB.  We were told that this was far too much and 
that we had to shrink it down a lot.  This is what I hope to start a 
discussion about.

As far as I can see, we can take 3 different approaches to lessen the kdelibs 
impact:

1. Make the application in question not use kde technologies at all and 
instead make it a pure Qt application. This would be a little like Marble in 
kdeedu that can be compiled both with a qt-only option to cmake or a kde 
option.  If there is an existing application that is already using much of 
kdelibs, it's more difficult but still doable.

2. Check the application in question and see exactly which part of kdelibs it 
is using and then create a tailor-made library with only exactly those classes 
that are used directly and indirectly.

3. Create a general kdelibs which still keeps the same API as the normal 
kdelibs, but which is much leaner and therefore also has much less features. 
In this case, we would have to create alternative classes with the same API, 
for instance a kde file dialog that just inherits QFileDialog and does nothing 
else. All of KIO would disappear at this point, which would lose us some nice 
features but save a lot of memory.

I will not touch approach 1 in this mail.  KO has started with approach 2 for 
KOffice. This approach is probably also usable if somebody wants to create 
stand-alone application packages for environments like Windows or MacOS X.

We have also combined this with a little of approach 3, so that we can achieve 
the absolute minimal kdelibs that fits the exact needs of KOffice on the device. 
The flip side of this is that no other KDE application will have much use of 
this library. Any other kde application would have to redo this work for 
itself. Therefore it is not packaged as kdelibs, but as libkok -- KOffice 
Kde(libs).

What I would like to discuss a bit more is approach 3. I see a lot of 
potential for kde technology on many different kinds of platforms. We have 
already today a plasma containment for netbooks, and I see no reason why a 
mobile phone couldn't be next. Even more interesting are running (variations 
of) kde applications on these platforms. Already today several KDE 
applications have two different UI's: the normal desktop one and a plasmoid.  
One that comes to mind is parley, also from kdeedu. So a third one with, say, 
a touch screen interface is not a far fetched thought.

To create a good kdelibs implementation with lots of flexibility and a span of 
features/resource needs we need some design. I imagine that at least the 
following needs to be done:

 * Some library reorganization.  I think there are some classes that should 
move between the libraries to reduce interdependencies. 

 * An idea of which features are necessary and which are possible to cut away.  
And then a clean way to build the libraries with all or parts of the removable 
modules disabled.

And maybe more.  If this is going to become a successful venture we need to 
cooperate and make the embedded kdelibs as important to us as the desktop is. 

Thoughts?

	-Inge