Minimal kdelibs on embedded platforms

[Benjamin Meyer]

On Nov 19, 2009, at 1:38 PM, Inge Wallin wrote:

> 
> 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.

4. Clean up KDElibs and Introduce a KDE4COMPAT compile time define.  Last I checked (long ago) kdelibs required the qt3compat library.  If this is still the case this should be the first project that is undertaken.  This will cleanup kdelibs, make it faster and leaner and prepare it for KDE5 all good things.  Next would be to create a KDE4COMPAT define and wrap around any api or class that is deprecated and has a replacement.  It would be worth making a Q4COMPAT define for Qt also to create smaller Qt binaries.  There are plenty of deprecated functions and classes in Qt that could be yanked out if you don't care about BC in the name of reducing the binary size.  Putting them in a define would be good.

Also you should never make a KFileDialog that just wraps QFileDialog.  If you are a KDE application and just just want a file dialog you can use the QFileDialog static functions and QFileDialog will call out to the KDE file dialog through hooks that are built into kio.  So if you are looking to make a minimal kde app this is one less api you have to worry about.

Just like with cpu profiling writing a little tool to profiling the library size would probably be a very nice thing (for this and many other projects).  Rather then guessing what is causing the 10MB libraries actually open it up and measure.  Just like with profiling we will probably be surprised by what you discover.

-Benjamin Meyer