kinetic-declarative plasma integration

[Alan Alpert]

On Mon, 18 May 2009 17:33:53 ext Aaron J. Seigo wrote:
> > > * i see things like Script { source: "weather.js" } in the examples;
> > > where do those scripts come from exactly? is it limited to files in the
> > > same directory? is there protection against requests for random files?
> > > can we hook our own "find the script" helper into it somehow?
> >
> > Yes, the scripts are loaded relative to the .qml file.  We are currently
> > thinking of the collection of .qml and .js files in a directory as a
> > "package" of sorts; that collectively define a component and its
> > behavior.
>
> while this can work, it's also not optimal. for instance, in Plasma can
> simply ask for the "image call foo" and it knows where to go looking
> without ambiguity introduced if there is a file called foo which isn't
> actually an image, something that is quite plausible when everything is one
> directory (esp if a GUI editor has been used to put everything together,
> btw, so the user is removed from these details one step further). that's
> just one example of how it can be nicer to allow location of files at
> runtime versus assuming their location.
>
> > We don't really want to introduce any form of search path which can just
> > lead to security concerns and user confusion.
>
> 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.

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

> > > * if one wants to create QML items dynamically, e.g. when a DataEngine
> > > returns a source create a new QML item and load it, how does that work
> > > exactly? can that be done from a JavaScript file?
> >
> > We have a couple of ways of dealing with "lists" of things (which sounds
> > like what the sources returned from a dataengine conceptually are).  All
> > of our view classes can take sets of things, and we also have a
> > generalized "Repeater" element for handling other cases.
>
> that will work for simple cases, but it would fail in the case of the time
> engine, for instance, where the list of available sources isn't the list of
> sources actually created. another example might be where the contents of
> one source changes and triggers the need to show other sources.
>
> i know that's not really "declarative" in nature, but it's the sort of
> manipulation that is very common. we can live without it, but it means that
> we won't be able to use the declarative UI stuff in some places. i suppose
> what we could end up doing is a bit of a hybrid in that case and create
> bits of QML on the fly in the regular C++ (or whatever language) code and
> use that to define parts of a widget.
>
You could do this declaratively instead. Just declare all the parts you're 
going to use and ones you aren't going to use now just stay hidden until you 
need them.

But we do mingle with the imperative with the JS if you want it. I expect that 
dynamic creation of items in QML will be possible, if not easy, by the end. 
I've actually done it before, but there's been a lot of changes since then so 
I'm not sure if it's currently working.

> > > * i see lots and lots of what look like pixel values in the weather
> > > example; are there more dynamic ways to define position such as "to the
> > > left of the Sun object" or "span the whole width, but offset by the
> > > height of this object from the bottom?"
> >
> > We have an inbuilt "anchoring" system for exactly this kind of thing. 
> > For example, here we anchor the moon to the left of the sun:
>
> 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.

> > > * how does scaling work? e.g. if i want an item in the interface to
> > > grow smaller when the container it's in grows smaller (think "layout
> > > like"), how does one achieve that?
> >
> > Layouting is supported, although as you've identified we have focused
> > mostly on fixed screen sizes.  We have vertical, horizontal and grid
> > layouts as well as the builtin "anchoring" system mentioned above.
> > Hopefully you'll eventually be able to use any custom Qt layouts you have
> > written.
>
> 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.

> > > * when it comes to the timelines and other animations, has any thought
> > > been put to how to map those to graphics APIs, e.g. OpenGL? in
> > > particular, with this high level sort of language it would be
> > > absolutely great to be able to determine what can be paralellized and
> > > what can't and then use that information in the painting layer if that
> > > information can be taken advantage of
> >
> > This has been the promise of every "declarative UI" solution ever
> > conceived. Unfortunately, none have really delivered on it.  I, too, hope
> > that we can take advantage of the additional context available and
> > automagically optimize the graphics stack.  This technology is still new,
> > so we'll have to wait and see what we can do.
>
> isn't it the sort of thing you probably want to consider in the design from
> the start so there's any chance at all of being able to deliver on it? my
> concern would be that the design may unintentionally make it impossible to
> deliver on this kind of feature unless the requirements are considered at
> an early enough stage.
>
> > > * when it comes to GUI editors for this language, how do you see
> > > timelining to be handled? will the GUI editor need to parse through the
> > > existing definitions and assemble timelines itself or is there a nice
> > > introspection API that can be used outside of actually running the
> > > resulting interface?
> >
> > A visual editor is a big part of what we want to enable.  Currently
> > there's no simple introspection API, so there's every chance that we'll
> > have to make some big changes before a final release to ensure that the
> > GUI editing experience is good.  Fortunately there's a bunch of people
> > looking into it
>
> great...
>
> > > * is it possible to hook into and control things like the animation
> > > pipelines? in particular, we need the ability to do things like turn
> > > off all animations on demand so that an animation just skips from 0.0
> > > to 1.0.
> >
> > Our focus so far has been principally on "fixed configuration" hardware
> > where this sort of configurability isn't necessary.  Of course, this
>
> right; it's pretty important for use where configuration isn't fixed,
> however. (to state the obvious :) .. i hope this becomes possible to
> control in the future so that we can take advantage of the declarative UI
> stuff in plasma at some point in the future.

We do intend to support non-fixed configurations before release. With regard 
to the animation pipeline we are moving towards using the new Kinetic 
Animations framework, which should hopefully provide you with the C++ 
interface you need.

> 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.
 
> thanks for keeping us in the loop and working with us to iron out the
> various issues. i know plasma isn't a "Fixed device display" and so is a
> bit of a different use case than i'm sure you've been addressing, but fixed
> device displays are not the future (or even all of the present), so i think
> this is a good exercise for the declarative UI stuff :)

With Qt everywhere we understand that there are a lot of different use cases 
and we do intend to address them all (if we can). We've merely started from 
more towards the "Fixed device display" side this time, and fully intend to 
address plasma's use case as well. It is certainly a good exercise for the 
declarative UI stuff. Thanks for working with us to find and iron out the 
various issues.

-- 
Alan Alpert
Software Engineer
Nokia, Qt Software