dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Aaron J. Seigo]

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

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

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

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...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100922/4047dc5d/attachment.sig>