Dataengines, libs and default config

[Petri Damstén]

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
>  here.
> 
> 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
>  "foundation"?

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.

Petri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090920/a5d82f6f/attachment.sig