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

Ian Reinhart Geiser geiseri at kde.org
Fri Nov 4 15:04:04 UTC 2005


On Thursday 03 November 2005 04:45 pm, Boudewijn Rempt wrote:
> On Thursday 03 November 2005 22:19, Adam Treat wrote:
> > Hi All,
> >
> > I would just like to point out that from discussions with the Ian, Aaron,
> > Matt, and Ryan at OSDW, I think the future of scripting in KDE4 might
> > follow a different path...
> >
> > There is talk of integrating the interpreter loading in the KParts
> > framework. This would allow us to have, among other things, genuine
> > KParts that could be written in several different languages as well as
> > embedded within regular C++ applications.  Regardless, I know Ian is
> > hoping to have kjsembed available to all KDE applications for KDE4.  I'll
> > let Ian and Aaron expand here, but I don't want to see KOffice apps
> > detour from the greater KDE scripting/binding community if it can be
> > avoided.
>
> Me neither, but with one big proviso: previous attempts at adding scripting
> to KOffice apps have always been halted because something great and KDE
> wide was going to come along in a moment. It never came along, and KOffice
> still doesn't have scripting. Five years or so after the Python community
> got all excited because KOffice was going to have Python scripting
> throughout...
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>.  At any rate no-one used it but Kate and KDevelop.  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.  

> So if this KDE4 magic doesn't materialize, fully-formed, including a
> usable, pluggable IDE for scripting and a sensible way for people to manage
> their scripts, in a very short time period, say before March, I guess we'll
> have to make do with what we can come up ourselves. Talk doesn't buy us
> anything but even more delays.
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".  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.  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.  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.  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.  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.

> 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 to heavy for automation scripting, and way to light for 
adding full plugins.  

> I miss Richard Dale in your cc-list, by the way... And maybe it would be a
> good idea to also add Phil Thompson, Simon Edwards and Jim Bublitz to the
> list of people who may have something interesting to say? They weren't at
> OSDW, but they all have worked on scripting bindings for Qt and KDE, and
> there isn't any larger KDE scripting/binding community than PyQt/KDE.
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)

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.

Cheers
	-ian reinhart geiser



More information about the Kde-bindings mailing list