last call for alcohol .. er .. BIC API changes

Richard Dale richard.j.dale at gmail.com
Mon Nov 3 21:52:24 CET 2008


2008/11/3 Aaron J. Seigo <aseigo at kde.org>

> On Monday 03 November 2008, Simon Edwards wrote:
> > Helloooo,
> >
> > Aaron J. Seigo wrote:
> > > i'd like to move libplasma over to kdelibs on Nov 3rd. it'll be a fair
> > > amount of work, and i'll announce here when i've started so other
> people
> > > don't get caught with local changes to libplasma.
> > >
> > > so this is the "last call" for binary incompatible API changes ... time
> > > to speak up or forever hold your peace, where "forever" is defined as
> > > "until kde 5"
> >
> > My only concern is that the script engine APIs seem to be missing a
> > number of methods which match the C++ API. For example, dataenginescript
> > doesn't have a counter part to "QStringList DataEngine::sources()" which
> > AFAIK makes it not possible to implement source listing functionality in
> > a scripted data engine.
>
> i sat down for five minutes and added the two most glaring missing things
> from
> DataEngineScript.
>
> in the time it took you to write that email, you could have done the same.
>
> > (Sorry, I don't have time right now to give more detail. Should the
> > scripting APIs be part of the BC API?
>
> yes
>
> > can that be delayed?)
>
> it's all be sitting there for nearly a year now and i get ~zero feedback
> from
> those who might use it. i honestly don't see that improving and as such
> don't
> see that as a reason to hold things up.
>
> ok, that's not quite true. i do see that improving when people start taking
> scripting seriously.
>
> i'm very surprised that the work going into scriptengines has mostly been
> in
> the form of writing bindings with little to no care as to what is actually
> in
> libplasma itself. that's a very poor model for creating scripting support
> for
> applications, imo.
>
> i had the bulk of feedback from the GoogleGadgets and Edje implementors,
> which
> is fasincating.

Well I think what Simon and myself are doing is different from what the
GoogleGadgets and Edje implementors were doing.

For better or worse we don't want to design a new api because we think the
C++ api is perfectly fine when translated method for method, and class for
class, to other more dynamic languages. I don't personally use the term
'scripting language' for this, because I don't see this to be anything to do
with scripting. To me scripting is all about driving a C++ application with
a lightweight language like Lua.

I see our work consisting of making the api that the RAD language
programmers sees as similar to the api that a C++ programmer sees. And
although I am perfectly happy with the results for the Ruby and C# script
engine apis, I really wish we had some users actually doing things with the
bindings to get more feedback about any changes before everything is frozen.

One little thing that would be nice, is to be able to specify a different
name for the main file in a plasmoid so that we can have main.rb, main.py
etc without needing to have a new package structure plugin just to be able
to do that.

-- Richard


>
> in any case, take the BC requirements as a call to action and look over
> those
> classes so we can get them into the order you'd be comfortable with.
>
> --
> 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 Software
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20081103/56b709ca/attachment-0001.htm 


More information about the Plasma-devel mailing list