Dataengines, libs and default config
Aaron J. Seigo
aseigo at kde.org
Fri Sep 18 20:43:20 CEST 2009
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
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"?
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 Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090918/5900d561/attachment.sig
More information about the Plasma-devel