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

[Sebastian Sauer]

Hi Ian, hi *,

Ian Reinhart Geiser wrote:
>> I miss [...] in your cc-list [...] And maybe it would be a good idea to
>> also add [...] to the list of people who may have something interesting to
>> say?
> 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.  

I hope we are able to do better then just ignoring each other cause that 
provides more problems as it solves some :) So, hopefully we are able to get 
some constructive talks up now.

First;

>> 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.

While I don't really understand why it's a way to light for adding full 
plugins cause we already use full plugins within Kexi, I like to add;

It's not about throwing kjs/kjsembed away / replacing it with Kross. It's all 
about the question what will be the best solution for kexi/krita/koffice. The 
time I started Kross I wrote at 
http://www.kexi-project.org/wiki/wikiview/index.php?Scripting#What_else_ 
already the note;

"Even if I don't hope that it will be the case, I guess we should keep in 
mind, that Kross may not the best / most powerfull solutions for next n 
years. Maybe some day I got enough free time and more experience to work on 
Kross2 or Trolltech starts to extend there QSA-solution to a LGPL Kross-like 
interpreter-layer. Whatever happens there next few years, we should try to 
design the integration flexible enough to be able to add or even replace the 
existing solution with another scripting-bridge. So, one more reason to try 
to work with flexible bridges between Kross and Kexi."

So, I am interested at the result and not the way it was archived. Beside the 
main goal to be interpreter-independent I even tried to minimize the areas 
where Kexi depends on Kross (as sayed that's right now exactly one single 
file in kexi/core).

> The 
> point is ECMAScript is the most popular scripting language out there. 

Well, even TT seemed to realize that there still exists Java. So, once a by 
them maintained and in Qt4 integrated solution is out and once KOffice is 
using Qt4 there should be really a way to let Java be a first class citizen 
in the used scripting-framework. 

It looks for me like specially cause of oo.org's Java-usage KOffice could 
profit a lot from being able to use Java too. Whatever will happen there next 
time, to cut down to one single interpreter and wrap the same 
application-/library functionality for each supported interpreter again looks 
for me like the wrong way to go.

> [...] KParts [...]

Is it possible to have a look at the work done so far on kjsembed4 / 
KParts-integration or to find somewhere more detailed infos? I know it's not 
ready yet, but at least some input how things should be archived in what ways 
could help a lot to solve a few questions.

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org/kexi && http://www.kmldonkey.org