dependencies on KJS/KHTML in kdelibs and kdebase-runtime
Aaron J. Seigo
aseigo at kde.org
Sat Sep 25 00:25:36 BST 2010
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
of thing, with QtScript being slightly higher level than either and with KJS
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
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
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
so we have KTranscript, KHelpCenter (or its replacement) and Kross that should
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
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?
> 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
> and QtScript compare?
> 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
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel