QML and Plasma -> progress()

[Marco Martin]

On Thursday 16 September 2010, Aaron J. Seigo wrote:
> On Thursday, September 16, 2010, Marco Martin wrote:
> > as i said, i don't think would really simplify the learning curve,
> > because one would have to manage two "types" of javascript, with a
> > difference between them that is quite an implementation detail (being on
> > two engines)
> 
> is it possible to include() other JS scripts from a QML Plasmoid package?
> because that's really what i'm most concerned about -> being able to use
> the JS API we have now to drive the QML.

it is possible to include separate js files, yes
and as far i know, all we can do to reuse our api is to register qobjects with 
our api with properties/signals/invokables.

AppletInterface works pretty well there, one can just register it t the root 
context as "plasmoid" and everything (almost) just works.

it is not possible to override plasmoid functions in javascript with things 
like plasmoid.dataUpdated = function() as far i know, but i could be wrong, i 
don't thik we really need this tough.

i -think- most of our bindings in javascript/simplebindings/  aren't of much 
use, since they use qscriptvalues, that is another thing that if it's used is 
buried pretty deep, all you pass around seems to be a simple qvariant, so 
simple thngs like colors,rects,sizes seems to just work.

> as for the engine not beign exposed, well .. i'm not surprised.
> 
> i have lost faith in the idea that QML development is in the hands of
> people who are competent enough with design for it to ever be an
> unqualified success. it will likely remain a land of promises half
> achieved and possibilities only half realized. i expect it to be forked /
> re-written (using the same language) at some point in the future with a
> reasonable API for developers using it. it's QtMultimedia all over again:

that's what i'm already hearing from several sources, basically wih the 
language everybody is almost happy, the implementation itself is unlikely to 
stay for long

> the same unwaranted bravado, the same potential in the design ideas if not
> the implementation, the same evident flaws that the developers are closing
> their ears to and therefore almost certain to have the same kind of result
> due to that.

yeah, what i'm concerned now is us using it in a way that will be as easy as 
possible to adapt.
it's a think that right now works almost well, even with those huge problems, 
so i think the benefit to use it now is relevant enough, especially if  this 
could become the only thing usable in some qgraphicsview replacement in the 
future.
but plans are so unclear and will change so many thimes still that meh... :/

Cheers,
Marco Martin