Minimal kdelibs on embedded platforms

[Aaron J. Seigo]

On November 19, 2009, Inge Wallin wrote:
> 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.

is advocating N forks of kdelibs really a step in any direction we could label 
"good"? or is it just a lot of developer overhead for a diminished user 
experience and software update hell?

> 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).

this definitely shows the problem with this approach. instead of having one 
clump of 10mb or whatever, we'll end up with N*X mb where N is the number of 
apps and X is the size of their libs. insanity :) 

and when we realize that kio, for instance, will be needed by some of those 
apps it becomes really apparent, at least to me, that saying things like "we 
don't need kio maybe" is short sighted. some app will need it. not providing 
it will mean that app either doesn't appear on the platform or else drags KIO 
along with it ... unshared.

so if we go down the path of modularizing kdelibs, let's try to ensure that 
the modularity is hidden from the apps as much as possible. in the case of 
KIO, what's the minimum we can provide for apps to be happy with? what can be 
added on app install to fill in gaps? 

at a minimum i imagine file:/// and http:// need to be supported in this case.

etc...

>  (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.

the point of the plasma approach is to hopefully avoid the "Nth interface" 
disease and have one that is simple but scalable and one that is a "full app".

>  * Some library reorganization.  I think there are some classes that should
> move between the libraries to reduce interdependencies.
 
do you have concrete examples?

>  * 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.

yes! :)

> 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.

if we can avoid having a split personality, we'll do a lot better because our 
app audience will be a lot larger. thinking in terms of a device spectrum 
might be useful; personally i don't think viewing different form factors as 
valid targets separate from others is very useful.

improving kdelibs for things like mobile is a Must Have(tm), making sure we 
don't end up with a mess will be the trick :)

btw, we already have the start of a plasma shell for the n900. it runs and 
works, including a special widget to trigger the app switcher. it is currently 
in playground and needs more work to get it to the point we could actually 
ship it. so we (plasma peeps) are quite interested in this topic.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091119/8f0d44d0/attachment.sig>