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

[Aaron J. Seigo]

On Monday 03 November 2008, Richard Dale wrote:
> 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. 

that's fine, but it doesn't help me understand the lack of feedback on these 
things or the hesitance to just add the methods needed to, e.g., 
DataEngineScript as they are found.

what fascinated me was that the people working on mating it with 3rd party 
APIs from outside of KDE were better at communicating their pain points. not 
sure the cause of that, but it's an interesting result.
 
> 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.

me too; i don't see that happening though.

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

i thought that was why we added the virtual mainScript method to ScriptEngine, 
but evidently that's not good enough.

something that occured to me is that you could always use the mainscript file 
to load 'main.py', no? one more bit of indirection, but you get your syntax 
highlighting that way ..

not overly elegant of course ... i'm seriously not impressed that we're 
looking at such complexity because of syntax highlighting in editors. =/

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

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