<br><br><div class="gmail_quote">On Thu, Nov 19, 2009 at 8:40 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A Dijous, 19 de novembre de 2009, Inge Wallin va escriure:<br>
<div><div></div><div class="h5">> As some of you may know, KO GmbH, the company I work for, has helped Nokia<br>
> port KOffice to Maemo and their new telephone n900. I think this is only<br>
> the first example of where KDE applications and maybe also (parts of) the<br>
> desktop will be used in embedded environments with other constraints than<br>
> the normal desktop.<br>
><br>
> One of the problems we have encountered was memory consumption and flash<br>
> disk space. Right now, the subset of 6 libraries from kdelibs we are using<br>
> have a footprint of a little over 10 MB. We were told that this was far<br>
> too much and that we had to shrink it down a lot. This is what I hope to<br>
> start a discussion about.<br>
><br>
> As far as I can see, we can take 3 different approaches to lessen the<br>
> kdelibs impact:<br>
><br>
> 1. Make the application in question not use kde technologies at all and<br>
> instead make it a pure Qt application. This would be a little like Marble<br>
> in kdeedu that can be compiled both with a qt-only option to cmake or a<br>
> kde option. If there is an existing application that is already using<br>
> much of kdelibs, it's more difficult but still doable.<br>
><br>
> 2. Check the application in question and see exactly which part of kdelibs<br>
> it is using and then create a tailor-made library with only exactly those<br>
> classes that are used directly and indirectly.<br>
><br>
> 3. Create a general kdelibs which still keeps the same API as the normal<br>
> kdelibs, but which is much leaner and therefore also has much less<br>
> features. In this case, we would have to create alternative classes with<br>
> the same API, for instance a kde file dialog that just inherits<br>
> QFileDialog and does nothing else. All of KIO would disappear at this<br>
> point, which would lose us some nice features but save a lot of memory.<br>
><br>
> I will not touch approach 1 in this mail. KO has started with approach 2<br>
> for KOffice. This approach is probably also usable if somebody wants to<br>
> create stand-alone application packages for environments like Windows or<br>
> MacOS X.<br>
><br>
> We have also combined this with a little of approach 3, so that we can<br>
> achieve the absolute minimal kdelibs that fits the exact needs of KOffice<br>
> on the device. The flip side of this is that no other KDE application will<br>
> have much use of this library. Any other kde application would have to<br>
> redo this work for itself. Therefore it is not packaged as kdelibs, but as<br>
> libkok -- KOffice Kde(libs).<br>
><br>
> What I would like to discuss a bit more is approach 3. I see a lot of<br>
> potential for kde technology on many different kinds of platforms. We have<br>
> already today a plasma containment for netbooks, and I see no reason why a<br>
> mobile phone couldn't be next. Even more interesting are running<br>
> (variations of) kde applications on these platforms. Already today several<br>
> KDE applications have two different UI's: the normal desktop one and a<br>
> plasmoid. One that comes to mind is parley, also from kdeedu. So a third<br>
> one with, say, a touch screen interface is not a far fetched thought.<br>
><br>
> To create a good kdelibs implementation with lots of flexibility and a span<br>
> of features/resource needs we need some design. I imagine that at least<br>
> the following needs to be done:<br>
><br>
> * Some library reorganization. I think there are some classes that should<br>
> move between the libraries to reduce interdependencies.<br>
><br>
> * An idea of which features are necessary and which are possible to cut<br>
> away. And then a clean way to build the libraries with all or parts of the<br>
> removable modules disabled.<br>
><br>
> And maybe more. If this is going to become a successful venture we need to<br>
> cooperate and make the embedded kdelibs as important to us as the desktop<br>
> is.<br>
><br>
> Thoughts?<br>
<br>
</div></div>Tell Nokia 10MB is cheap these days.<br></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Albert<br>
<br>
><br>
> -Inge<br>
><br>
<br>
</blockquote></div><br>