[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Minimal kdelibs on embedded platforms
From:       Benjamin Meyer <ben () meyerhome ! net>
Date:       2009-11-20 3:26:28
Message-ID: B03E0024-96E6-4208-A285-7BCA54F3D236 () meyerhome ! net
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]