Minimal kdelibs on embedded platforms

Inge Wallin inge at lysator.liu.se
Fri Nov 20 09:28:59 GMT 2009


On Thursday 19 November 2009 23:22:28 Aaron J. Seigo 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?

To be clear:  I'm not advocating it, although I can understand how that could 
be inferred from what I wrote.  I'm just saying we took this approach as a 
quick hack to get something that works fast.  And methinks your quoting skills 
need a brush up.  The word I actually used was "useful". :-)

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

Yes.  This is what I mean and you clarified it very well.

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

That sounds intriguing, I wasn't aware of that.  Is this actually spelt out 
anywhere?  And does plasma handle touch screens already?
 
> >  * Some library reorganization.  I think there are some classes that
> > should move between the libraries to reduce interdependencies.
> 
> do you have concrete examples?

Let me get back to you about that.

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

Nothing to add here.  It sums up the problem beautifully.

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

Interesting!  Where can we find out more?

	-Inge





More information about the kde-core-devel mailing list