dependencies on KJS/KHTML in kdelibs and kdebase-runtime
Aaron J. Seigo
aseigo at kde.org
Wed Sep 22 18:23:29 BST 2010
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,
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
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
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.,
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
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