dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[John Layt]

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 
benefits.

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 
here still?

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.

Cheers!

John.