kross in kdelibs

[Sebastian Sauer]

Hi dear devels,

Chapter 1: The intro

Something like 1.5 years ago work on a framework to provide embedded scripting 
for applications was started. Since that time the code improved, growed, got 
ported, followed KISS and therefore got smaller, got new bugs, new fixes and 
is finally near a shape where I guess other applications outside of KOffice 
could start to profit from it.

For a more detailed intro you may like to take a look at 
http://dot.kde.org/1152490640/ and move back into the time to attend my 
somewhat unprofessional but funny aKademy-presentation :)

For those who missed the link above, let me copy+paste at least the intro 
sentence;
[quote]
Kross is the scripting engine for KOffice and provides a complete framework to 
embed scripting interpreters transparently into native applications and 
bridge the static and dynamic worlds together to be able to extend an 
application with scripting code.
[/quote]

Chapter 2: The proposal

The current situation within KOffice-trunk based on KDE4 is, that Krita and 
KSpread (Kexi is not portet yet to Qt4) are using the Kross-library. I have 
talked with developers of akanodi, amarok, kopete and kommander, and they 
have at least expressed an interest in the framework.
While there are still some pending tasks I like to have done within next week, 
I guess we reached now a somewhat (more) stable stage where other 
applications may like to start to use that framework too. Since not every 
application may like to depend on koffice-libs, my proposal is to move parts 
of the code to kdelibs.

Chapter 3: The code

If we do a quick svn co and take a look at koffice/libs/kross/ we are able to 
see the both directories "core" and "modules". While the code located 
in "core" provides mainly some abstract functionality to deal with the 
dynamic loadable interpreter-plugins, modules and actions (which are 
high-level scripts), the "modules" directory contains dynamic loadable 
plugins with additional optional functionality. The "python", "ruby" 
and "kjs" directories are the interpreter-plugins which depend then on 
python, ruby and kjs+kjsembed. My proposal would be, to move the 
core+modules+kjs (not more then a skeleton yet, needs more work within next 
weeks/months) functionality to kdelibs and have the python+ruby plugins 
outside (e.g. at kdebindings or even better - eh, another proposal ?! - split 
kdebindings into kdepython, kderuby, etc.).

That way we are sure, that applications using Kross are able to optional use 
python, ruby or whatever else someone likes to provide support for while 
kjs+kjsembed is just always supported cause it's at kdelibs anyway.

Chapter 4: Before

Before the code may got moved, I would for sure add d-pointers and 
virtual_hook's (for any not qobject-derived class) everywhere, extend dox, 
fix remaining issues, move the guimanager.* functionality to 
the "modules"-directory and propably get right of the 
errorinterface+childinterface classes.

Chapter 5: After

While the python-backend works great, ruby needs some additional work (~3 
weeks) to reach the same level and then I would start to concentrate on the 
kjs-integration (~n weeks) to have it as first class citizen. For sure it 
would be prefered to have within the kjs-directory as less code as possible 
and just extend kjsembed where possible/needed (if the needed extensions are 
ok'd by kjsembed-devels for sure, else I need to find another solution to get 
kjs just working). That way we would have with kjs one always available 
backend while other backends are still optional supported. So, one of the 
design-goals was to don't focus on any language language specifically rather 
then offering just optional support to with whatever languages 
users/developers like to use. So, any preference on a specific language is 
irrelevant for this framework!

Regarding who's working on the code: for sure myself who is a strong python- 
and perl-lover and Cyrille Berger who wrote the ruby-backend. Since I believe 
in doxygen, I'll also try to get at least at the core enough dox in to double 
the loc next few months and provide enough input for others to get fast an 
impression how the things are working together.

Chapter 6: Feedback

and now I wait for any questions, proposals, wishes, ideas, ... from you :)

-- 
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 && http://www.kmldonkey.org