dependencies on KJS/KHTML in kdelibs and kdebase-runtime

Alexander Neundorf neundorf at kde.org
Sat Sep 25 15:58:40 BST 2010


On Saturday 25 September 2010, Volker Krause wrote:
> On Saturday 25 September 2010 01:25:36 Aaron J. Seigo wrote:
> > On Friday, September 24, 2010, John Layt wrote:
> > 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.
>
> Kross already has a QtScript backend, so there is no need to port its KJS
> backend at all :)
>
> This only really leaves KTranscript in kdelibs as something that would need
> porting to QtScript I think, and from the Kontact Mobile POV I'd obviously
> welcome that. We have stripped out KJS/KHTML dependencies to reduce disk
> and memory usage for that already, the KMail message viewer is based on
> QtWebKit, the Kross parts have been changed to use the QtScript backend
> (which in most cases just meant renaming the files from .js to .es), and we
> have splitted up the packages in such a way that we don't install things
> depending KJS/KHTML by default (khelpcenter for example, which doesn't
> really work on mobile screens anyway, but right now also KTranscript).

I think Volkers post makes it very clear that what Aaron wrote is factual 
reality and not kjs/khtml bashing.
To me this looks like there is actually nothing to decide, since there is only 
one option left which makes sense.

Alex




More information about the kde-core-devel mailing list