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
