Minimal kdelibs on embedded platforms

[Albert Astals Cid]

A Dijous, 19 de novembre de 2009, Inge Wallin va escriure:
> 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?

Tell Nokia 10MB is cheap these days.

Albert

> 
> 	-Inge
>