dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[John Layt]

On Wednesday 22 September 2010 18:23:29 Aaron J. Seigo wrote:
> 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 use, imho.

For KTranscript and anything else in kdecore, I'm inclined to agree, kdecore 
should have the minimal requirements, if Qt provides a good-enough solution 
then we should use that.

For the wider kdelibs/kdebase-runtime I think we need more info, or 
at least in my ignorance I don't know what the consequences exactly are. 

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?

What else in kdelibs/kdebase-runtime depends on KJS/KHTML?  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?

With javascript performance being so talked about these days, how do KJS 
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 bitrot?

If there is no downside technically, then it becomes a strategic decision, but 
no less easier to take.

John.