|
»
« Return to Thread: Fwd: Re: Scripting in Kile
Re: Fwd: Re: Scripting in Kile
by Dominik Haumann-3
::
Rate this Message:
Hi,
> > [...]
> > 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 these objects with own functions. Right now, I do not know how
> > this works.
more on this in a separate mail.
> 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 the
> engines global object and put its own into the engine.
>
> - if Kate doesn't offer an engine, we should discuss why not ;-)
As Kile is the host application, it sounds weird that kate part should
deliver the scripting engine. For me, it is much more logical that Kile
provides the engine, and puts into the scripting context whatever it needs,
and part of that is the Cursor/Range/View/Document api.
Another reason why Kile should provide the script engine is that Kile can
just plugin in the QObject pointers of the KateScriptView and
KateScriptDocument. Hence, the implementation is still completely internal
to kate part - and that would be a good thing, as we do not have to care
about binary compatibility of the public KTextEditor interfaces.
> > Next, as said, Kile's interface is based on the Cursor & Range api [2].
> > 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 javascript code like "Cursor.insertSection = function()
> > {...};" (bad 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.
Of course, that makes sense. But I'm sure there are other classes where such
an extension would be handy. Think of a special "DocumentCursor" that
provides cursor movements based on a associated document:
var dc = new DocumentCursor(document, new Cursor(0, 0));
dc.moveToNextWord(); // could be provided by Kate Part
dc.moveToNextSection(); // must be provided by Kile
(We have this as C++ class: BoundedCursor, WrappingCursor etc... Exposing it
in the scripting api makes very much sense...)
But ok, for a start Cursor + Range is fine.
> > [...]
> > 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.
>
> Yes, definitely.
>
> And perhaps KateScriptView/Document can take some code from
> KileScriptView/Document for some more basic functions of
> KTE::View/Document.
Yes, I'll take a look into that and extend the Kate view API accordingly at
some point.
To sum up: As Kile is backward compatible to older KDE versions, Kile would
need to maintain two implementations. From Kile's perspective, just for the
sake of sharing code, this does not make much sense.
But for KDE 5, sharing the code is very much desirable. So trying to keep
compatibility now should be high priority.
So we target KDE 5 for the code sharing ?
This would mean for the Kate developers to find a good interface + find ways
how Kile can extend our view/document scripting objects.
Greetings,
Dominik
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@...
https://mail.kde.org/mailman/listinfo/kwrite-devel
> > [...]
> > 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 these objects with own functions. Right now, I do not know how
> > this works.
more on this in a separate mail.
> 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 the
> engines global object and put its own into the engine.
>
> - if Kate doesn't offer an engine, we should discuss why not ;-)
As Kile is the host application, it sounds weird that kate part should
deliver the scripting engine. For me, it is much more logical that Kile
provides the engine, and puts into the scripting context whatever it needs,
and part of that is the Cursor/Range/View/Document api.
Another reason why Kile should provide the script engine is that Kile can
just plugin in the QObject pointers of the KateScriptView and
KateScriptDocument. Hence, the implementation is still completely internal
to kate part - and that would be a good thing, as we do not have to care
about binary compatibility of the public KTextEditor interfaces.
> > Next, as said, Kile's interface is based on the Cursor & Range api [2].
> > 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 javascript code like "Cursor.insertSection = function()
> > {...};" (bad 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.
Of course, that makes sense. But I'm sure there are other classes where such
an extension would be handy. Think of a special "DocumentCursor" that
provides cursor movements based on a associated document:
var dc = new DocumentCursor(document, new Cursor(0, 0));
dc.moveToNextWord(); // could be provided by Kate Part
dc.moveToNextSection(); // must be provided by Kile
(We have this as C++ class: BoundedCursor, WrappingCursor etc... Exposing it
in the scripting api makes very much sense...)
But ok, for a start Cursor + Range is fine.
> > [...]
> > 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.
>
> Yes, definitely.
>
> And perhaps KateScriptView/Document can take some code from
> KileScriptView/Document for some more basic functions of
> KTE::View/Document.
Yes, I'll take a look into that and extend the Kate view API accordingly at
some point.
To sum up: As Kile is backward compatible to older KDE versions, Kile would
need to maintain two implementations. From Kile's perspective, just for the
sake of sharing code, this does not make much sense.
But for KDE 5, sharing the code is very much desirable. So trying to keep
compatibility now should be high priority.
So we target KDE 5 for the code sharing ?
This would mean for the Kate developers to find a good interface + find ways
how Kile can extend our view/document scripting objects.
Greetings,
Dominik
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@...
https://mail.kde.org/mailman/listinfo/kwrite-devel
« Return to Thread: Fwd: Re: Scripting in Kile
| Free embeddable forum powered by Nabble | Forum Help |
