QtScript considered dangerous

[Milian Wolff]

Hey all,

I just wanted to notify you that a fix to this notorious QtScript bug was 
released in time for 4.8.3. For now, I can retract my statement that QtScript 
should be considered dangerous :) So Kate can stick to QtScript and I don't 
have to port it to KJS at the upcoming hack sprint!

See also:
https://bugreports.qt-project.org/browse/QTBUG-23871
https://bugs.kde.org/show_bug.cgi?id=297661

The patch can be found here:
https://codereview.qt-project.org/#change,32359

Many thanks to Kent Hansen for fixing this bug!

Cheers

On Thursday 24 May 2012 10:59:21 Dominik Haumann wrote:
> Hi Milian,
> 
> CC: kde-core-devel, as this is really a tough issue...
> 
> there are other applications like Kile that heavily use QtScript for
> scripting as well, so porting away KatePart from QtScript may solve the
> issue for KDevelop, the real problem lies (as you say) within QtScript, not
> Kate. The reason for why we use QtScript are:
> - QtScript is very (!) easy to use
> - QtScript is maintained (at least at that time?)
> - really good documentation
> 
> There are other arguments, why we finally ended up with QtScript:
> - kjs is pretty much undocumented, meaning that it's not immediately clear
>   e.g. how to export custom classes and so on.
> - at the time we dropped kjs, it wasn't clear whether it's going to be
>   maintained and improved (the speed in QtScript was much better). At that
>   time, there were even lots of people shouting "drop khtml" etc...
> 
> Initially, KatePart even used kjs and the code was a lot more complex to get
> the same thing as we have now with QtScript. That alone is a strong
> argument for using QtScript.
> 
> With regard to Kate, we are about to export our js-API so that other classes
> can use our returned QScriptValues. Once this is the case, we cannot go
> back due to BIC reasons. So this is a tough issue... We can go back to
> using kjs again, of course, but then, I still have lots of questions [1]
> :-)
> 
> What about other solutions: Reduce memory consumption in KDevelop?
> Another question is: Maybe we'll have similar/other issues with kjs? ;)
> 
> Greetings,
> Dominik
> 
> [1] http://kate-editor.org/2012/05/12/rfc-exporting-javascript-api/
> 
> On Wednesday, May 23, 2012 22:08:08 Milian Wolff wrote:
> > Hey all,
> > 
> > I have a sad discussion to start it seems:
> > 
> > We have port Kate away from QtScript.
> > 
> > See also:
> > 
> > https://bugs.kde.org/show_bug.cgi?id=297661
> > https://bugreports.qt-project.org/browse/QTBUG-23871
> > 
> > This is the number one reason for crashes I get recently, and makes
> > KDevelop unusable. Apparently Kate usually doesn't that issue since it
> > doesn't use as much memory as KDevelop (see the Qt bugreport).
> > 
> > The bug report is open since ~4 months without any feedback from any Qt
> > developers. Today I had a chat with a few Nokia Qt developers at LinuxTag
> > and they said they will probably not spent the considerable amount of time
> > in updating the archaic jsc checkout used in QtScript. Apparently, Digia
> > is supposed to handle Qt 4.x issues like these and seriously, they don't
> > really do anything as long as a commercial customer of them requires a bug
> > to be fixed...
> > 
> > Since this issue renders KDevelop unusable (crashes with stack corruption
> > or assertion every few keypresses that issue a run of the indenter script)
> > I really think we should look for alternatives.
> > 
> > So - what are the reasons that Kate uses QtScript instead of KJS? I hope
> > that we can easily port our existing code to KJS without a too high
> > performance impact, something I'll measure of course. But are there other
> > reasons beside performance?
> > 
> > /me who is angry at Digia/Nokia/Qt for not fixing this mess
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120813/40e604a5/attachment.sig>