dependencies on KJS/KHTML in kdelibs and kdebase-runtime
Aaron J. Seigo
aseigo at kde.org
Wed Sep 22 21:37:20 BST 2010
On Wednesday, September 22, 2010, Harri Porten wrote:
> On Wed, 22 Sep 2010, Aaron J. Seigo wrote:
> > furthermore, it is has become quite evident that on these devices,
> > anything requiring KJS/KHTML will not make it onto them.
> Begs the question how much of KDE will make it onto these devices at all.
as much as we can get on them. that's the goal, at least, and we're making
reasonable progress i think. not all the decisions are easy or go our way,
some do. more when we try.
> Isn't it all duplication?
from what i've been seeing first-hand, we have a lot of unique and useful
things to offer this space. lots of work is left to do, of course (as always
:), but there are many things of interest. whether it's koffice's mobile
incarnation, kontact mobile which is really coming along, plasma on things
like tablets, marble for truly open nav ... there are lots of useful things
that are easiest or only possible right now from KDE if you want Open. in our
libraries there are lots of nice jewels as well that make app dev a lot
easier. but we know all of that, i'm preaching to the choir here. fortunately,
that choir is slowly getting larger thanks to people taking it out there to
various places, be it PCs in schools or mobile phones.
right now it's causing forks to form beneath us, though, as different groups
groom different versions of kdelibs in different ways. we can avoid this with
some fairly straightforward decisions which from a purely technical POV makes
sense as well. my hope is that we can spread kdelibs further by drawing these
efforts together and make our upstream kdelibs better in the process by
getting those efforts improving kdelibs directly instead of their forks-of-
that work, much of which is already being done by people we've known for years
within the KDE community, if drawn upstream will benefit all users of kdelibs,
including those targetting the desktop.
> And looking at how slow 4.x still is on many
> desktop PCs I don't see e.g. Plasma "fly" there either.
we definitely struggle with a lot of driver issues out there, that's for sure.
and we continue to find ways to optimize our code.
on mobile, things are a bit more well defined hardware wise, but we face
issues there as well. they are actively being worked on, with plasma-mobile
making good progress and really pushing things, and as a result we're seeing
> Hence the KDE project might be careful what to put its cards on.
i certainly don't think we should bet the whole house on mobile. 330 million
laptops/desktops a year say otherwise. the growing number of set top boxes for
t.v.'s say otherwise. tablets say otherwise (though i guess those could be
seen as a specialized form of mobile...). no, we need to look at the whole
device spectrum imho and try to build a core platform that works well across
some of our apps (and our libraries) will target just parts of that spectrum,
e.g. Digikam might always remain a "desktop" app due to its use cases and that
would not be a bad thing in the least imho while Kontact Mobile certainly is
going to be less than useful on your desktop. :) we're seeing more diversity
in our application targets, and that's a very good reason to pragmatically
assess and work on our base platform as supporting that diversity is not
trivial. but then, that's what KDE is good at: non-trivial pragmatism. :)
so i definitely agree with you that we shouldn't bet on mobile as a future
saviour; it's just one more great opportunity to bring software freedom to the
world, in pantone 330C with a gear on the side ;)
> Doesn't take away the freedom to try it, of course.
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel