Minimal kdelibs on embedded platforms

[Albert Astals Cid]

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.

Albert

> 
> > Albert
> >
> > >       -Inge
>