dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Aaron J. Seigo]

On Friday, September 24, 2010, John Layt wrote:
> Could you explain a bit more what we would lose by the move, i.e. what does
> KJS provide that QtScript does not?  Do we lose any localization or
> integration functionality by such a move?

we don't lose anything. in fact, we gain a fair amount of ease of use as 
QtScript actually sits on top of JavaScriptCore from WebKit providing a Qt 
style API. JavaScriptCore and KJS are probably closer to being the same kind 
of thing, with QtScript being slightly higher level than either and with KJS 
having some extra Qt sugar that JavaScriptCore doesn't.

the performance of QtScript, since moving to JavaScriptCore, is remarkably 
good. i've been measuring the performance of it in the context of Plasma 
(Plasmoids, DataEngines, etc) and have been pleasantly surprised. to get many 
of our code paths to show up in timing runs i have to repeat them 100s or 
1000s of times :)

(where it hits QGraphicsView, particularly with regards to 
QGraphicsProxyWidget, is a completely different and unrelated matter and not 
quite so cheery a story)
 
> What else in kdelibs/kdebase-runtime depends on KJS/KHTML? 

usage of KJS in kdelibs:

* KTransrcript in kdecore
* KJSEmbed
* Kross, for its Javascript backend
* KHTML

usage of KJS in kdebase/runtime: none that i could find.



usage of KHTML in kdelibs: none that i could find (kcookiejar installs some 
files into share/apps/data/khtml, but it doesn't link against it or otherwise 
require it).

usage of KHTML in kdebase-runtime:

* khelpcenter (QtWebKit has what it needs now; though when i asked about 
porting it some months ago, i was told that a replacement was in the works and 
so not to bother if it wasn't critical)

* a handful of control panels in kcontrol/ have "khtml" in their name, but 
they don't link to khtml and fwiu are also used to configure KWebKit when it 
is used


so we have KTranscript, KHelpCenter (or its replacement) and Kross that should 
be ported.

the builk of KTranscript is not actually reliant on a given JS engine and is 
dedicated to the actual translation bits. it's a few days work to port and 
test, though.

it may be better to just wait for KHelpCenter's replacement. barring that it's 
another few days of (admitedly boring) work to use QtWebKit instead. 
KHelpCenter uses the DOM API to perform a few navigation related tricks. this 
would need to be implemented with QDom*.

Kross's JS support is 364 lines of code. if we subtract the factory class that 
is not KJS specific (it's Kross specific) then we have 320 lines, all in one 
file. it's extremely pedestrian code, and should actually shrink significantly 
in a move to QtScript. for someone with even moderate experience with QtScript 
(e.g. myself) it's a day's work.

> What will they lose (if anything) in the process?  

nothing.

> What will the KDE development platform
> lose by their being excluded from the mobile space if they don't switch?

KTranscript provides advanced i18n for more complex languages.

KHelpCenter isn't applicable to the smartphone area, but on tablets it would 
be good to have for reading documentation. (it can be patched around without 
too much hassle, but that's the kind of thing i'm trying to prevent here)

Kross would lose nothing; if anything, it probably will get faster for 
Javascript.

> With javascript performance being so talked about these days, how do KJS
> and QtScript compare?

http://digitizor.com/2010/08/12/how-much-faster-is-konqueror-with-webkit/
 
> What is Qt's commitment like to QtScript, I assume now it is part of Qt
> core it's not about to be dropped for something trendier or left to
> bitrot?

it's used by QML, it uses JavascriptCore from WebKit (shared with QtWebKit, of 
course). unless Qt changes the HTML rendering engine used (WebKit) or decides 
web content, declarative UI, etc. are no longer interesting, then it should 
remain supported and actively developed.
 
> If there is no downside technically, 

actually, technically there's upside: we get away from having multiple JS 
interpreters and HTML stacks loaded, performance of QtScript is better, 
QtWebKit isn't tied to QWidget for painting, etc.

> then it becomes a strategic decision, but no less easier to take.

yes, it's primarily a strategic decision. for me the primary issue is 
preventing forks of kdelibs (by our own community, no less!) and drawing 
everyone's efforts on kdelibs development closer together by acknolwedging the 
realities of the day: some of KDE is working hard on mobile devices where 
KJS/KHTML simply isn't part of the picture, Qt provides good (and in some ways 
better) options, which originally derived from KJS/KHTML, with a large 
developer ecosystem around those tools.

if i had my way, there would be no WebKit, it would have been all KHTML and 
we'd not be having this discussion. i believe most (if not all) of us probably 
feel similarly. that isn't how it played out, however. while there wasn't 
anything to lose while remaining with KHTML and KJS (esp while options were 
not mature enough to reasonably consider them) it didn't matter. but now we're 
running into real world trade-offs and inneficiencies, both technically as 
well as community wise.

-- 
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/20100924/c321ce0f/attachment.sig>