Dataengines, libs and default config
petri.damsten at gmail.com
Sun Sep 20 10:20:50 CEST 2009
On Friday 18 September 2009 21:43:20 Aaron J. Seigo wrote:
> On September 18, 2009, Petri Damstén wrote:
> > > > Currently making a weather applet is much harder in scripting
> > > > languages because you don't have access to the library.
> > >
> > > can't you build some QScript bindings for it? then the applet can
> > > request that add-on?
> > Yes of course but I was thinking some common way that would not require
> > generating bindings for all available scritpengines.
> there are a few ways to go about this:
> a) go around making bindings for multiple languages over and over. not
> realistic, imo
> b) create a generic interface to specific kinds of things that then each
> script engine maintainer can look after
> c) concentrate on the JS bindings and make those top tier and not worry too
> much about whether there are equal features in every single script engine.
> (c) is what i'd like to see us do. there are already differences between
> the script engines (obvious ones like google gadgets vs pythonoids; less
> obvious ones like python libs that aren't available in ruby).
> we really ought to be promoting JS as the preferred way to write plasmoids
> anyways and given that we have limited resources and no suitable CLR type
> thing realistically at our disposal, let's just concentrate on QSCript
> so.. what would it look like?
> i think most sensible would be a way to register families of widget types
> (weather, clock, etc). perhaps we can call them "widget foundations", since
> you build on top of them? each foundation would provide a factory for
> creating instances of an applet with some QScript hooks that can be
> exported into the runtime, perhaps as part of an object named
I think most of the kde-look.org plasmoids are made with python (quick check
from 20 highest rated is about 90%). I personally don't like the idea of
letting those to be second class citizens.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090920/a5d82f6f/attachment.sig
More information about the Plasma-devel