<br><br><div class="gmail_quote">On Thu, Nov 19, 2009 at 11:22 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On November 19, 2009, Inge Wallin wrote:<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>
</div>is advocating N forks of kdelibs really a step in any direction we could label<br>
"good"? or is it just a lot of developer overhead for a diminished user<br>
experience and software update hell?<br>
<div class="im"><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>
</div>this definitely shows the problem with this approach. instead of having one<br>
clump of 10mb or whatever, we'll end up with N*X mb where N is the number of<br>
apps and X is the size of their libs. insanity :)<br>
<br>
and when we realize that kio, for instance, will be needed by some of those<br>
apps it becomes really apparent, at least to me, that saying things like "we<br>
don't need kio maybe" is short sighted. some app will need it. not providing<br>
it will mean that app either doesn't appear on the platform or else drags KIO<br>
along with it ... unshared.<br>
<br>
so if we go down the path of modularizing kdelibs, let's try to ensure that<br>
the modularity is hidden from the apps as much as possible. in the case of<br>
KIO, what's the minimum we can provide for apps to be happy with? what can be<br>
added on app install to fill in gaps?<br>
<br>
at a minimum i imagine file:/// and http:// need to be supported in this case.<br>
<br>
etc...<br>
<div class="im"><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>
</div>the point of the plasma approach is to hopefully avoid the "Nth interface"<br>
disease and have one that is simple but scalable and one that is a "full app".<br>
<div class="im"><br>
>  * Some library reorganization.  I think there are some classes that should<br>
> move between the libraries to reduce interdependencies.<br>
<br>
</div>do you have concrete examples?<br>
<div class="im"><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>
</div>yes! :)<br>
<div class="im"><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>
</div>if we can avoid having a split personality, we'll do a lot better because our<br>
app audience will be a lot larger. thinking in terms of a device spectrum<br>
might be useful; personally i don't think viewing different form factors as<br>
valid targets separate from others is very useful.<br>
<br>
improving kdelibs for things like mobile is a Must Have(tm), making sure we<br>
don't end up with a mess will be the trick :)<br>
<br>
btw, we already have the start of a plasma shell for the n900. it runs and<br>
works, including a special widget to trigger the app switcher. it is currently<br>
in playground and needs more work to get it to the point we could actually<br>
ship it. so we (plasma peeps) are quite interested in this topic.<br>
<font color="#888888"><br></font></blockquote><div><br>/me will work on it as soon as 4.6.0 is out!!<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888">
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
</font></blockquote></div><br>