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 m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.