[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Fwd: Re: Scripting in Kile
From:       Dominik Haumann <dhdev () gmx ! de>
Date:       2012-01-18 20:21:00
Message-ID: 201201182121.00743.dhdev () gmx ! de
[Download RAW message or body]

Forward to have the discussion public :-)

----------  Forwarded Message  ----------

Subject: Re: Scripting in Kile
Date: Wednesday, 18. January 2012, 16:32:29
From: Holger Danielsson <h-danielsson@versanet.de>
To: Dominik Haumann <dhdev@gmx.de>

Hi Dominik,

> In order to share code, I quickly talked with Christoph and we came up 
with
> 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 [3] and returns this pointer as QVariant.
> - add a property to KTextEditor::Document (e.g. scriptObject), that 
creates
>   an instance of KateScriptDocument [4] and returns this pointer as
> QVariant.
> 
> Kile can then query the KTE::View/Document for this property to get the
> scripting object, and put it into the QScriptEngine (newQObject(...)), 
just
> like you do right now with your own implementations (KileScriptView,
> KileScriptDocument).
> 
> 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. 

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 ;-)

> 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.
  
> To wrap up: The property system allows Kate Part to deliver all the stuff
> Kile needs without braking binary compatibility (KTextEditor interfaces 
are
> 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.

Yes, definitely.

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.

ciao holger

-----------------------------------------
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]