Fwd: A help with JS (or maybe also Python) plasmoid

[Aaron J. Seigo]

On Tuesday 24 June 2008, Richard Dale wrote:
> 2008/6/23 Aaron J. Seigo <aseigo at kde.org>:
> > On Monday 23 June 2008, Janz wrote:
> > > give any hint) and couldn't find about how to get started with a
> > > non-C++ plasmoid. I saw a few examples (tiger JS plasmoid and all of
> > > those in script/ on svn playground) but I can't install them under KDE
> > > 4.1 beta Kubuntu package
> >
> > we actually have a plasmapkg application in kdebase now that can install
> > such
> > packages.
>
> I would like to be able to use the plasapkg packaging mechanism for non-C++
> languages such as C# which don't use the ScriptEngine api. 

which is completely plausible; the two aren't actually linked in any way. we 
use packages for other things as well, e.g. themes.

> C# is not a
> scripting language and I think people will expect either the C++ api or
> nothing 

makes sense. in which case C# just becomes Another Language which libplasma is 
unaware of. this means less integration and no out of the box magic.

personally, i don't see why, in light of that, we need such languages, other 
than to inflate the language count, when we have a number of alternatives. but 
if people wish to write in C#, go for it by all means.

> - I really can't see how it would make sense to go through the
> ScriptEngine.

i don't want to compromise the tidyness of it on the libplasma side, however.

> There will be the same issue if we have Java QtJambi bindings
> I think. I have exchanged private emails with Aaron about whether or not
> Ruby should use the ScriptEngine, and I still am not keen on using it as it
> currently stands.

then it becomes like the C# issue above. a proper API for applets written in 
Ruby can also be provided via ScriptEngine at some point. it's not an 
either/or, it's really a matter of doing it in a way that lets plasma help you 
or whether you are completely on your own.

obviously, integration points and easing support of managing packages, etc is 
probably the nicest thing. doesn't mean it's the only thing.

>  I personally would prefer to get something going for 4.1 because I don't
> think we can know what people want - which languages, what skill level and
> so on - until we start iterating with something and get community feedback.

agreed; but what's actually *ready*?

> change. All I know is that the current group are all 100% 'ninja' to use
> Aaron's terminology and would expect to be able to use the full C++ api. So

and we'll never get the other 98% of people unless we adjust ourselves from 
catering to those people.

> my plan for KDE 4.1 is to try and provide both a ScriptEngine based api,
> and the full C++ api (with or without proper plasma packaging), and get
> something moving.

cool; i guess that answers my what's actually read question above.

> In a couple of weeks we are having a hacker sprint in Berlin with a lot of
> the bindings guys (python, ruby, c# and php) and Kross too, and I would be
> very keen on discussing there what to do about Plasma bindings for KDE 4.1.

i just hope that the point, purpose and advantage of the ScriptEngine strategy 
isn't lost because people are still thinking about things in the traditional 
manner of "wrap an API, it's what we want!" versus "define an API, it's what is 
manageable and increases the audience"

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080624/72b0aa8c/attachment.pgp