Minimal kdelibs on embedded platforms

[Alexis Ménard]

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.


>
> Albert
>
> >
> >       -Inge
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091130/6efc2f75/attachment.htm>