Subject: Re: Scripting in Kile
Date: Wednesday, 18. January 2012, 16:32:29
From: Holger Danielsson <h-danielsson@...>
To: Dominik Haumann <dhdev@...>
> In order to share code, I quickly talked with Christoph and we came up
> the following solution: Since KTextEditor::View/Document derive from
> QObject, we suggest to
> - add a property to KTextEditor::View (e.g. scriptObject), that creates an
> instance of KateScriptView  and returns this pointer as QVariant.
> - add a property to KTextEditor::Document (e.g. scriptObject), that
> an instance of KateScriptDocument  and returns this pointer as
> Kile can then query the KTE::View/Document for this property to get the
> scripting object, and put it into the QScriptEngine (newQObject(...)),
> like you do right now with your own implementations (KileScriptView,
> Now, since Kile certainly wants to provide its own additional functions to
> the "view" and "document" object, we have to check how Kile can extend
> objects with own functions. Right now, I do not know how this works.
Same here. And i can't imagine that this will work with an already created
instance of KateScriptView/Document. But perhaps you will find a way ;-)
But this is easily possible: KileScriptView/Document inherit from
KateScriptView/Document. Then Kile can add its own functions and
- if Kate offers a QScriptEngine (i think it will), Kile can remove it from
engines global object and put its own into the engine.
- if Kate doesn't offer an engine, we should discuss why not ;-)
> Next, as said, Kile's interface is based on the Cursor & Range api .
> Since KateScriptView and KateScriptDocument depend on the Cursor & Range
> api, Kile would need to make sure this api is loaded beforehand.
> A solution to this is to add a property to KTextEditor::Editor (e.g.
> scriptingApi), which is a QStringList of the _content_ of 05_cursor.js and
> 10_range.js [5, 6]. Kile then can iterate through the QStringList and
> evaluate each item in the script engine.
> Again, Kile might have need of additional functions in the Cursor & Range
> classes. This can be done by modifying the prototype, i.e. by evaluating
> example). So this should not be an issue.
No problems. And both are rather complete now. Perhaps you can also add my
small changes in range.js, then there will be no need to add something.
> To wrap up: The property system allows Kate Part to deliver all the stuff
> Kile needs without braking binary compatibility (KTextEditor interfaces
> frozen in KDE 4.x.).
> A benefit would be, that Kate Part internal scripting code can be use by
> Kile, Kate, KDevelop etc... And another huge advantage is, that our
> document scripting already provides functions that are not publically
> available via the KTextEditor interfaces.
And perhaps KateScriptView/Document can take some code from
KileScriptView/Document for some more basic functions of KTE::View/Document.
As already Michel answered:
I tried to aim at 100% compatibility with the KatePart API so that at some
point a KTextEditor interface could be introduced which would allow Kile to
access and extend the scripting API of KatePart.