kross in kdelibs
mail at dipe.org
Thu Oct 19 17:16:33 BST 2006
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
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.
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
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]
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org
More information about the kde-core-devel