kinetic-declarative plasma integration

[Aaron J. Seigo]

On Monday 18 May 2009, Alan Alpert wrote:
> On Mon, 18 May 2009 17:33:53 ext Aaron J. Seigo wrote:
> > i'm not asking for a search path, but a locator, which is exactly what
> > Plasma::Package is. it handles security in a clean, central manner while
> > making it the opposite of confusing for the user.
>
> You can hook your own "find the script" helper function in somehow. Either
> filtering the file property in your own items or making a locator function
> available in the JS (providing similar behavior to the C++) should be
> possible already. We'll look into a better method though.

yes, we could provide our own locators, making the QML-for-plasma a bit more 
plasma-specific that it otherwise would be, but it's already going to be 
dragging some non-standard-QML things in there anyways (e.g. DataEngines) so 
it wouldn't be a huge deal.

as long as we can reference the locators for images, scripts, etc from the QML 
itself we'll be golden.

> > > > * can we populate the JS runtime with whatever we want, or are we
> > > > limited to a QML JS runtime?
> > >
> > > At the moment the QScriptEngine that we instantiate internally is
> > > "ours". We don't allow applications to twiddle with it in any way. 
> > > What sorts of things would you like to do to it?
> >
> > it would be nice and useful if we could inject all the objects/properties
> > we do in the javascript ScriptEngine: DataEngines, Services,
> > configuration, etc.
>
> You can expose objects and properties to QML as you do with the Javascript
> script engine. I'm not as certain about the prototypes but because QML is
> used in a different way than pure JS you shouldn't need them.

i'm not so concerned about the QML itself as the JavaScript that gets executed 
alongside it.

> > i suppose the anchoring system documentation is still coming, or is there
> > something i could go and read right now?
>
> anchor-layout.html (Reachable from the QtDeclarative Module page) in the
> Declarative UI docs should give you a basic overview right now.

great, i'll take some time to read over it ..

> > and QGraphicsLayout i imagine :) i'll keep an eye on this aspect of the
> > project as well in my "list of things to consider when we can pull the
> > trigger to use it in plasma"
> >
> > personally, i don't see the point of having a third layout system just
> > for the declarative UI framework (we have QLayout and QGraphicsLayout
> > already)
>
> The "third" layout system would be one solely for the Declarative QML. From
> C++ we intend to let you use QGraphicsLayout. The point is that you need to
> be able to use items in QML that are designed to be used declaratively, and
> neither current layout system was so designed.

is it possible to add this to the QGraphicsLayout system? if it needs to all 
be worked around, so be it, but if it's possible to extend and improve what 
exists that would be a bonus in my books.

> > it seems that as it stands right now, there's a few blockers to seriously
> > using this in plasma. the idea is great, the implementation is obviously
> > unfolding .. it just probably needs more time.
>
> It has plenty more time, don't worry. It's great if you clearly list any
> blockers from your perspective so that we can look into them as early as
> possible. I will of course look into all of the issues you've raised in
> this email.

and that's really appreciated, btw .. :)

-- 
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/20090519/c65e3881/attachment.sig