[Kde-bindings] KOffice Scripting for KDE4 (Was Re: Moving kross(kexi/scriptingcore) in libs)

Fri Nov 4 17:59:58 UTC 2005

On Friday 04 November 2005 16:04, Ian Reinhart Geiser wrote:

> Yes, this was kind of a downer.  Back in KDE 3.0 when I introduced our
> common bindings layer with dcop the python and perl camps basicly said
> "No".  They didn't want to use DCOP because <fill in some irrational reason
> that has no technical merit>. 

I was using PyQt at the time, but I don't remember any reasons, or even any 
discussions. I just know that in the past year, whenever I was able to 
convince myself that my work wouldn't be wasted because of that infernal 
d-bus, I've been trying to get dcop-enable Krita.

I discovered that:

* The documentation available is completely useless for anyone trying to 
create a rich dcop interface for their application
* That when I finally have mapped with a lot of effort the classes I want to 
expose in dcop, that it's not obvious at all how the mappings should be used. 
* That I should probably provide a wrapper library in every language I care 
about to hide the awful details of dcoprefs and dcopobjects. Especially 
dcopref... Why don't the python bindings know the interface to object behind 
the dcopref?
* That I couldn't find out how on earth to add the KScriptInterface thingy to 
Krita (and couldn't even find out what it did, exactly, for KDevelop, so I 
didn't have useful example).
* That I was very jealous of the OO people with their UNO and their Java, 
Python and Basic language bindings.

Of course, I'm a pretty average idiot, so had I been smarter, I probably could 
have managed, but I've read all available documentation and pretty much gave 
up. And if d-bus hadn't loomed all the time, I would have put even more 
effort into the attempt.

> At any rate no-one used it but Kate and 
> KDevelop.

And Krita. At least I tried. In the end, I think that dcop-enabling an 
application the size of Krita is just too much work, and that the client 
tools are too unfinished. Even kdcop can't do anything with a dcopref -- how 
lame is that?

> To this day all we have is KJS, Python and Bash.  Now that dbus 
> wont work in process I am not sure how feasable it will be to continue
> this.  Therefor, I have decided to go the ECMAScript route.

I don't follow the reasoning, but then, I wasn't at the discussions -- because 
I didn't know they were being held that day.

> At Akademy it was decided that ECMAScript support was to be added at the
> core of KDE.  KJSEmbed is moving into kde's core libraries and will provide
> a scripting and automation interface for all KDE applications.  This will
> be done in a similar manner that dcop is done now.  Now you may ask "Why
> ECMAScript?  Why not Python?  Why not <fill in my pet language>"  Well the
> answer is pretty much "No-one cares". 

The problem with ecmascript is that it doesn't give me access to a rich 
library like Perl, Python or Java do, out of the box. But basically, you're 
right, I don't care about the language. I care about 

> If they cared about using all of the 
> languages they would have jumped on the KScriptInterface back in 3.0.  The
> point is ECMAScript is the most popular scripting language out there.  TT
> has done a few studies, as well as the fact that pretty much every web page
> out there uses ECMAScript.

Sure. But I bet that VBA is used way more than javascript. And that's the 
scripting language I'm worrying about.

> Now beyond automation support there are KParts. 
> KDevelop and KOffice are all currently extended with KParts.  You can even
> write Python and Java KParts.  This is Today, been that way for almost 2
> years.  Again, we don't push it, but that is another issue. 

Of course, these things need time to mature, become known and get used. Two 
years is no time at all. Anyway, I don't use Java because Java doesn't 
integrate into the build process of a KDE application. PyKDE/PyQt are used a 
lot. But I'm not to interested much in KParts anyway. Most of the objects I 
want to expose to scripting authors aren't kparts, and most of the scripts I 
envision Krita users want to run aren't kparts either.

> The big 
> technical issue is these abilities are not part of KParts itself.  They use
> bootstrap KParts and for each interface you must provide a binding and a
> special KPart.  This pretty much limits us to the basics.  To get around
> this KParts needs to have more knowledge than just C++ shared libraries.  
> The second technical hurdle (there are a few ideas to solve this currently)
> is to dynamicly provide the interface to the target language.  

Yes, dcop ought to have done that, of course. Because it didn't, dcop-python 
is all but useless.

> This way you 
> can just grab the interface description and run with it.  This also needs
> to be solved to help get around BC issues in KPart interfaces.  

Doesn't that assume that all objects available from the script are QObjects?

> The  last 
> issue is the workbench and debugger.  Now that Richard Moore and I have
> worked out many of the sticky bindings issues, we have started on the
> debugger and workbench.  With the new Qt Designer and text editor
> interfaces we already have nice things like syntax highlighting and
> breakpoints.  The next step is to hook up Designer actions to KJS methods. 
> Maybe not by march, but we will be ready for KDE 4 with basic
> functionality.

Maybe something for KOffice 2.0, if we can find a way to get rid of the 
ecmascript limitation by then -- and that's not the chain-yanking of a Python 
lover, or a javascript ignoramus. In an enterprise, you need Java. In an 
enterprise moving from MS Office, you need a Basic.

> > Personally, I think the Sebastian Sauer's kross thing is pretty cool --
> > and given that it works already, maybe something for the dreamers to take
> > a look at? And build upon kross, instead of reinventing the wheel again?
>
> I am not sure what kross gains us.  It seems pretty unclear what use it
> really would be.  Its way too heavy for automation scripting, and way to
> light for adding full plugins.

I don't doubt Sebastian will be able to answer that better than me.

I'm just quite convinced that kross makes it easy to make an application 
scriptable from simple task automation that goes a little beyond macro 
recording, to adding full blown plugins to an application like Krita -- 
plugins that can implement any interface C++ plugins can implement. And I 
don't want more. (Although scriptable IPC would be a Good Thing, too.)

Python, dcop, qsa, kjsembed -- the list of technologies that were history 
before lowly app developers got a chance is long. Too long.

> Well there are two parts to this.  The big one is that pretty much everyone
> has made a pretty obvious effort to not work together.  Its either their
> way or their way.  Really I am tired of it, and pretty much joined them in
> that optinion.  The only difference is that I want to solve this in a
> manner so we don't have to care.  By making KParts the interface, there
> only has to be one plugin layer, then the higher level language people just
> have to bind to the kparts interfaces, and build the proxy to forward the
> interface methods. Again PyQt, Java and KJSEmbed have already solved this. 
> I think Ruby may have too, but I have not seen the bugger in action.  The
> point is that once KParts is extended the fruits of Richard Dale will be
> sampled by every KDE application that uses KParts. (read pretty much every
> KDE application)

So, basically, a kpart interface will be what a kdcop interface is now? Up to 
now, a kpart to me is just a convenient way to automatically load a plugin 
that gets loaded for every view in my KOffice app...

> One thing I would like to make clear.  I am not against Kross, and I don't
> care if Kexi or Krita etc use it.  They are the developers, and I have
> absolutely no control over them.  I just wanted to let you guys know what
> is brewing down in the kdelibs guts.

I'm still not sure I actually understand what's going on -- and not convinced 
that it'll actually fill the needs for a scripting component for an office 
suite. I guess the requirements for that are:

* be able to expose any object, not just qobjects
* be able to work in-process and out-of-process
* scalable from simple scripts to full-blown components consisting of several 
source files
* have an IDE and a debugger
* be language agnostic
* be able to create user interface and merge things with the parent's user 
interface
* be able to use language libraries installed on the system outside the 
scripted application

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20051104/79242084/attachment.sig>