Minimal kdelibs on embedded platforms

[Alexis Ménard]

On Thu, Nov 19, 2009 at 11:22 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

> 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.
>
>
/me will work on it as soon as 4.6.0 is out!!


> --
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091201/2bf0effe/attachment.htm>