dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Aaron J. Seigo]

hi all ...

those of us working on smaller-than-laptop form factors with kdelibs have been 
faced with doing varying degrees of hack-and-slash to the libraries there to 
get them to an appropriate form for the target devices.

on such devices, KJS and KHTML are usually left off since other alternatives 
already exist and such duplication of functionality is a non-starter. this is 
generally ok, save for  few odd spots.

one is KTranscript in libkdecore, used for advanced translation. it is driven 
by snippets of ECMAScript and uses KJS to drive this. it is rather odd to have 
a dependency between libkdecore and KJS in this case (libkdecore should 
probably just depend on Qt), but on devices it would be far more desirable to 
have KTranscript use QtScript which already will be on the devices and used 
extensively by other software on these devices (be it QtQuick, plasma, 
whatever).

Chusslove, author/maintainer or KTranscript, is Ok in theory with migrating 
KTranscript to QtScript, though he doesn't have time to do so himself. which 
is fine: we can find the resources elsewhere. but he wanted discussion here 
first before making such a shift. i agreed that this is sensible, ergo this 
email :)

to be clear: regardless of whether this is the desire of upstream KDE or not, 
KTranscript will not be shipping using KJS on such devices. this means either 
a QtScript implementation downstream that doesn't get upstream testing (not 
great), or it just gets dropped on the floor altogether (and i18n suffers on 
those devices).

so i'd prefer to see a QtScript implementation for KTranscript hit upstream.

furthermore, it is has become quite evident that on these devices, anything 
requiring KJS/KHTML will not make it onto them. 

let me state what should be the obvious: i think it is terrific that people 
continue to work on KJS/KHTML and enjoy improving them, release after release. 
i think it is terrific that people continue to use KJS/KHTML with, e.g., 
konqueror.

now for the perhaps less obvious: that does not mean that the rest of kdelibs 
(or the SC modules, even) need to therefore use KJS and KHTML as their 
defaults. for the world of devices, it just doesn't make sense to do so. for 
the desktop, particularly apps showing app generated HTML content, it's 
probably less of an issue.

so now the proposal:

i'd like to propose that we deprecate the usage of KJS / KHTML in kdelibs and 
kdebase/runtime/ with the intention of moving what code does use it to 
QtScript or QtWebKit. both are mature enough to take on this weight, and are 
what we are having to use on devices anyways.

i don't think we need to make any policy with regards to applications in 
general, as it's really the base system that is of most concern when it comes 
to this issue. app developers should continue to choose for themselves what to 
use, imho.

-- 
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/0d175525/attachment.sig>