Why KDE, and Kate

I’ve been using and contributing to KDE on-and-off for a while, but our friends over in Gnome land were already busy by the time I got into the game. So why did I conceptually commit to KDE, and thence Kate? Consistency.

I grew up on VAX/VMS where it was possible – and even easy – to mix Ada code with C and Pascal, mix in a CLI that used the standard parser, generate error messages that looked and *were* like every other message in the system. Everything felt integrated.

And the editors? Ah yes, the editors. VAX EDT was where I started, and I *loved* the fact that I used the same editor whether I was writing a VAXmail, posting a VAXnote, or editing a file. So it was a bit of a dilemma when I encountered VAX Emacs, with all its seductive extensibility. I ended up using Emacs for serious editing, and EDT for everything else…that was hateful. Eventually, TPU and its precocious offspring LSE restored the status ante, and my sanity.

Scroll forward a few years, past Windows NT 3.5 and Visual Studio where I got hooked on GUIs, and we get to Qt and KDE libs. Even though there were several KDE text editors in those early days, it was a reasonable bet we’d rationalise, and I’m delighted to say we did (even when Kmail’s default isn’t KWrite – at least the look’n'feel was the same). I even went round making every Find and Replace dialog throughout KDE the same.

So we get to Kate. Right out of the box, even in its Kate 3 incarnation, I loved Kate. Standalone was good, in KDevelop it was even better. I didn’t miss the relative lack of extensibility because well, it did pretty much everything I wanted. And then I changed job…

RFC: Exporting JavaScript API

Since quite some time, Kate Part has build-in scripting support through JavaScript. Our plan is to make this API public, so other applications like Kile, Kate App and KDevelop can use it. However, we are currently unsure how to best implement it, so this is a rfc to get feedback.

The bindings for a Kate Document are for instance located in part/script/katescriptdocument.h (header, implementation). As you can see, there are functions like

Q_INVOKABLE bool insertLine(int line, const QString &s),

which can be invoked in our scripting by a call of ‘document.insertLine(5, “hello world”)’. The API only contains basic functions. But for instance Kile maybe also wants to provide a function called ‘document.insertSection()’ or similar LaTeX related functions. The question now is as follows: How can Kile extend our QObject based prototype with their own QObject based classes?

We do not want to make the class KateScriptDocument public. Instead, we just want to return a QScriptValue containing a QObject based KateScriptDocument. You can think of the problem also as follows:

// in Kile:
QScriptEngine *engine = ...;
KTextEditor::Document *kteDocument = ...;

QObject* kateScriptDocument = kteDocument->scriptDocument();
engine->globalObject().setProperty("document", engine->newQObject(kateScriptDocument));
// at this point, the JavaScript object 'document' contains all KateScriptDocument functions

// next, we want to add the Kile related document functions
KileTextDocument* kileDocument = ...;
QObject* kileScriptDocument = kileDocument->...(); // some function that returns the binginds object

// now: how can we populate the 'document' property with the functions in kileScriptDocument?
engine->globalObject().setProperty("document", ? );

If you have any idea or other solutions how to do it right, please let us know!

Crash through D-Bus calls

Years ago, there was a blog on the planet with the title “How to crash (almost) every Qt/KDE Application and how to fix it“. In short, if you are showing a dialog, KWin prevents you from closing the application by clicking on the close button in the window decoration. However, through D-Bus, you can still quit the application. A solution was also provided: Use a guarded pointer to create the dialog.While this fixes the issue, it looks like fixing the blame, and not the real issue. Stricktly speaking, even the Qt documentation would be wrong then.

Searching for ‘Accepted’ on lxr.kde.org shows lots of dialogs that lead to possible crashes. I wonder whether developers are really aware of this crash? Even if we took care of this issue as proposed, it’s just a matter of time until dialogs are created the `wrong’ way again (do we have krazy checks for that?). In Kate, no one took care of this situation, meaning that you can indeed crash the application through D-Bus.

Is there a better way to fix this?