[Kde-bindings] Fwd: A help with JS (or maybe also Python) plasmoid

Richard Dale richard.j.dale at gmail.com
Tue Jun 24 21:12:18 UTC 2008


2008/6/24 Aaron J. Seigo <aseigo at kde.org>:

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

Yes, I can write a Ruby plugin type that would load pretending to be a C++
plugin and then load the ruby code using the plasma packaging api. It's
just  that it wouldn't be built into Plasma like the ScriptEngine/Package
loading is. I think that is the best solution for KDE 4.1, and what I will
try to actually implement.


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

Umm, the problem is that the current ScriptEngine api doesn't offer 'out of
the box' magic apart from the packaging mechanism. It may in the future, and
maybe knowledge about the security api would affect my opinions. I can only
see what I currently see in the code.


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

Yes, I would class C# bindings in the 'for educational use' category. That
is a use case would be for people who want to spend a weekend or two playing
with a language like C#, and a relatively small self contained api  like the
Plasma one, hacking up a clock or something with no practical value. Of
course once we actually have C# programmers my opinion may well change.


>
>
> > - 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*?

Well nobody is working on improving the script engine api, it has stayed
unchanged for over 2 months. I did ask about the method to invoke a config
dialog a while ago, saying that the ScriptEngine api didn't allow you to
access a KConfig instance to save the api details. Of course you can just
access the underlying applet to do that, but would that be following the
script engine api? Or are you just supposed to go via the provided methods
and wait for more methods to be added in the future.


More information about the Kde-bindings mailing list