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