[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: dependencies on KJS/KHTML in kdelibs and kdebase-runtime
From:       Alexander Neundorf <neundorf () kde ! org>
Date:       2010-09-25 14:58:40
Message-ID: 201009251658.40385.neundorf () kde ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]