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

[Stefan Champailler]

Dear All,

I'm following this discussion from quite a distant point of view. Anyway, I'd 
like to tell my little story.

I use Korundum and co happily. However, I use that not to script KDE directly 
but actually to quickly build some GUI on top of some Ruby code. That is, I 
write my tool first with Ruby and then, when it's needed, I make a small GUI 
with KDE. It's not unlikely that for example I use Ruby to query a database 
of URL's, open those URL's with wget, parse the result with Ruby's regexp and 
browse the result with some Qt interface or feed the result to some other KDE 
application...

The moral of the story is that a good scripting language etc. is OK but one 
shouldn't forget that what can be interesting is to use the language to glue 
the power of its libraries with the power of KDE. It's not just about 
scripting KDE component.

Voilà ! Just to insist on something I read in the mail below...

Stefan

(and no, I'm not Ruby-only, whatever allows me to solve my problem :))




> 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