Like last summer I am mentoring a student working on Kate’s Vi mode this summer. This year’s student is Vegard Øye from Oslo, Norway. I’ll let him introduce himself:
My name is Vegard Øye. I am a computer science student at the University of Oslo, Norway. I also have a bachelor’s degree in electrical engineering from Sør-Trøndelag University College in Trondheim, where I programmed for integrated circuits. It was a lot of fun, so I decided to embark on a grade with an even larger emphasis on programming.
My goal is to make modal editing more widespread outside of Vim. There is a Zen-like benefit to using a tool that does just what you tell it to – slicing and dicing text with surgical precision. My focus is not on adding new features to Kate (although I have implemented a few), but on sharpening existing functionality. In particular, I want to improve the integration between Kate’s vi mode and its extension system, as well as sort out various bugs pertaining to the vi mode.
Vegard has already done some really great work, and his changes should be trickling in to Kate’s git repository the next weeks. You can follow his work at http://quickgit.kde.org/index.php?p=clones%2Fkate%2Fvegardoye%2Fvegard_gsoc_2012.git.
One year more passed and the next Akademy will soon open its doors.
Was never before in Tallinn or Estonia, will be an interesting visit.
Hope to meet again a lot of old and new KDE people.
Didn’t code a lot at all since last years meeting, too busy to finalize my phd thesis.
Hope to get more time for Kate in the next months again 😉 And at the meeting.
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();
// 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!
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?