Minimal kdelibs on embedded platforms

[Inge Wallin]

On Tuesday 01 December 2009 01:02:29 Albert Astals Cid wrote:
> A Dilluns, 30 de novembre de 2009, Alexis Ménard va escriure:
> > On Thu, Nov 19, 2009 at 8:40 PM, Albert Astals Cid <aacid at kde.org> wrote:
> > > 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.
> >
> > Just so you know we are talking about the memory when library is loaded.
> > A phone doesn't have 2GB of RAM. KOffice might also be one day on low end
> > devices where is the memory is a luxury. Don't think only about your own
> > computer and multiply it by millions of device. It does not cost nothing.
> 
> According to what i spoke with Inge on IRC long ago he was speaking of disk
> not RAM.

1. You sent the reply asking me.

2. I was wrong :-)