kinetic-declarative plasma integration

[Alan Alpert]

On Tue, 19 May 2009 17:07:25 ext Aaron J. Seigo wrote:
> 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.

When I've been referring to QML I include the JavaScript in a QML file as 
well. And that includes .js files included via a Script element. The 
distinction is a little blurry because many of the expressions in a QML file 
are JavaScript, like all of the property values.

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

If they end up providing similar behavior to QGraphicsLayouts then we'll 
probably make the QML items QGraphicsLayout subclasses. That would only 
change how they appear in C++ though.

However, we've found that our layouts have been behaving differently so far, 
due to the nature of Fluid UIs. They are a lot less standardized, and so tend 
to have irregular layouts, where the central area is managed by anchors. So 
layouts like vertical layouts tend to only be used for groups of things, like 
from a Repeater. This makes them Items which layout children, and not item 
layout managers that arrange children to fill an item. Additionally, anchor 
based layouts and the ability to use bindable expressions for properties like 
width lead to a reduced need for a layout that scales your items based on 
min/max and preferred dimensions. So our layout items currently are 
fundamentally different. It remains to be seen whether this is the right 
choice, and we're eager to hear your feedback after you try it.

Note that the common cases, like just filling a parent item, are easily 
handled by anchors, like  'anchors.fill=parent'.

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

-- 
Alan Alpert
Software Engineer
Nokia, Qt Software