dependencies on KJS/KHTML in kdelibs and kdebase-runtime
johnlayt at googlemail.com
Fri Oct 1 20:14:33 BST 2010
On Saturday 25 September 2010 00:25:36 Aaron J. Seigo wrote:
> 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.
OK, so just to wrap-up, there are currently only 3 areas affected:
KTranscript: The only real area needing work, generally agreed a QtScript port
would be a good thing as it minimises the dependencies and may have speed
Kross: We have both QtScript and KJS backends available, so no major work is
really required. Do we need to do anything to the build system to make
compiling the KJS backend optional depending on platform profile? Is there an
easy way to transparently switch between backends depending on what is
installed without having to change the script suffix as Volker suggests? Can
an app set a preferred backend to use if available?
KHelpCenter: Aaron is investigating a rumoured re-write, but either way it's
unlikely to be used on a mobile platform in its current implementation. A
more mobile friendly implementation would be welcome.
Would I be right in thinking that if apps use the KPart it will automatically
switch between khtml/kjs or kdewebkit/qtscript depending on what's available
on the platform and not notice a difference in most cases? Or is work needed
It remains important for us to maintain khtml/kjs, both due to api guarantees
and as a safety net. No-one should be discouraged from working on or using
khtml/kjs (especially if that is their "itch"), and apps are still free to
choose to use khtml/kjs.
More information about the kde-core-devel