QtScript considered dangerous

[Dominik Haumann]

On Monday, August 13, 2012 15:44:43 Milian Wolff wrote:
> 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!

Which implies that now you have a lot of free time to hack on Kate, Cheers!

> 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!

Right, thanks for taking care of this + keeping us up to date.

Greetings,
Dominik

> 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