Question about C++ vs. Python/Ruby/JS plasmoids

[Richard Dale]

2008/9/1 Arne Babenhauserheide <arne_bab at web.de>

> Am Mittwoch 27 August 2008 18:38:05 schrieb Aaron J. Seigo:
> > this is a feature also provided by ECMA Script. the question is "why
> $LANG"
> > instead of just stickign to ECMA Script.
> >
> > the reasons i see are:
> >
> > * you know $LANG, or the project your are integrating with is written in
> > $LANG
> >
> > * in the cases you need access to more system libraries, but don't want
> to
> > write in C++ (Ruby/Python have bindings for pretty much everything)
>
> * in the cases where the languages are just better suited to the task. For
> example String operations, using anything from the standard library (if "it
> does the task for you" counts as being better suited :) ) or glueing things
> together in Python.
>
>
> How about using Kross to enable Plasmoids scripted in any language?
> - http://kross.dipe.org/
> - http://techbase.kde.org/Development/Tutorials/Kross/Introduction
>
> A possible first step could be a Plasmoid which takes its data from a Kross
> script.

That is what the script engine DataEngine api is for, and we have language
bindings for that.

Note that Kross is intended for scripting existing applications, it isn't a
language independent library for implementing language bindings. We have a
system for doing that called 'Smoke', which is used currently for the Ruby
and C# bindings.

If plasma applets actually need scripting support (I'm not convinced they do
personally), then from what Aaron has been saying about minimizing
dependencies, maybe the core applets should standardize on QScript. If you
write a non-core applet in Ruby or Python, I'm not sure if having a
scripting api makes sense anyway.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20080901/fc57c7eb/attachment.htm