kinetic-declarative plasma integration

[Marco Martin]

On Thursday 14 May 2009, aaron.kennedy at nokia.com wrote:
> Hi Aaron,
>
> Great list of questions!  I apologize in advance if my answers are a little
> "qml general" rather than specific to the plasma integration, but I'd
> prefer to let Alan handle those details rather than me just getting them
> wrong :)
>
> On 14/05/09 10:30 AM, "ext Aaron J. Seigo" <aseigo at kde.org> wrote:
> > * where can i find the qml language definition?
>
> Sadly a formal language specification hasn't been written yet (short of
> reading src/declarative/qml/parser/javascript.g which probably isn't what
> you want :)  The "QML For C++ Programmers" documentation shows you all 
the
> things you can do, but not in a formal way.
>
> Obviously this sort of documentation is essential for the released product!
>
> > * why does it implement it's own canvas system? i suppose the idea is to
> > allow non-QGraphicsView uses of this? a huge downside i see to this
> > approach is that there are now two places to get things wrong (and trust
> > me, if this ends up anything like QGraphicsView things will go wrong
> > repeatedly, it's just the nature of the beast) and two transformation
> > management code paths (to pick a random example) to have fun working 
out
> > the interactions between. is there really no way to have a common system
> > for this?
>
> Part of what we're exploring with this project is a new way of doing
> graphical UIs.  In addition to just the declarative language, this involves
> experimenting with things like how to best integrate OpenGL, measuring the
> maximum achievable performance and exploring any opportunities for
> optimization the "declarativeness" might give us.  To help with this the
> declarativeui can use its own canvas system.
>
> This is only a temporary situation - we fully intend to have only one
> canvas system at release time!
>
> > * how will this work with things like QGraphicsItem, which aren't
> > QObjects? will there be a QGraphicsItem bridge written or will we need to
> > roll our own? or will this simply be limited to QObject?
>
> Currently the QML engine can only create, and set properties on QObject
> derived types.  We're currently debating whether we should add support for
> wrapping non-QObject types - is the complexity of the wrapper itself and
> managing tricky details such as detecting instance deletion worth it?
>
> Fortunately you're not entirely out of luck.  We do support Qt interfaces
> (of which QGraphicsItem is one) so you can do:
>
> class MyWrapperType : public QObject, public MyGraphicsItemType
> {
> Q_INTERFACES(QGraphicsItem)
> };
>
> And then assign that type to a Qt property of type "QGraphicsItem *".
>
> > * there is a *lot* of manual API wrangling in the examples, such as:
> >
> >     QmlContext *ctxt = m_engine->rootContext();
> >     ctxt->activate();
> >     ctxt->setContextProperty("applet", this);
> >     m_root = m_component->create();
> >     ctxt->deactivate();
> >
> > that honestly looks pretty clumsy. what would make a lot more sense to me
> > is something like:
> >
> > {
> >     QmlContext ctx(m_engine);
> >     ctx.setContextProperty("applet", this);
> >     m_root = m_component->create();
> > }
> >
> > this hides all the "implementation detail" stuff; e.g. why should i care
> > about activating and deactivating the thing? for the internals, i get it,
> > but as an external API it seems like too many implementation details are
> > leaking out.
> >
> > as i look through the examples i see a lot of similar cases. thoughts?
>
> EEK!  Sounds like a left over from the early days when you *did* have to
> manage your contexts manually.
>
> Now you can just write:
>
> QmlContext *ctxt = new QmlContext(m_engine.rootContext());
> ctxt->setContextProperty("applet", this);
> m_root = m_component->create(ctxt);
>
> You still have to allocate your context on the heap, as when it is
> destroyed all the binding expressions that depend on it are invalidated.
>
> I'll make a note to track down and eliminate all that misleading example
> code.
>
> > * 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.
> We don't really want to introduce any form of search path which can just
> lead to security concerns and user confusion.
>
> > * same for question for other resources like pictures
>
> Same answer :)  I believe the plasma specific items do use the kde theme
> system to locate images and the like, but I'll have to let Alan handle the
> details on that one.
>
> > * 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?
>
> > * 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.

i'm indeed playing with views now.
since the qml documentation appears still not there i'm going by attempts:
what classes are for views? until now i've found ListView and GridView, 
anything else?
also, is it possible to do an horizontal list view?
but the real question is: is it possible somehow to plug a traditional qt 
model into it?

> For example, were your data engine to expose a list of its available
> sources, you could write QML like this to list all their names.
>
> VerticalLayout {
>     Repeater {
>         dataSource: MyDataEngine.availableSources
>         component: Text { text: dataSourceName }
>     }
> }
>
> If the available sources changed, this list would be updated accordingly.
>
> > * 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:
>
> Moon {
>     anchors.right: TheSun.left
> }
>
> and here we create a solar eclipse:
>
> Moon {
>     anchors.centeredIn: TheSun
> }
>
> We're currently still working on getting the anchors and the animation
> system to work seamlessly together in every case, which is probably why the
> weather example doesn't use them everywhere.
>
> > * 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.
>
> Here's a simple example of two rectangles in a horizontal layout.
>
> HorizontalLayout {
>     Rect { width: 100; height: 100; color: "blue"; }
>     Rect { width: 200: height: 100; color: "red"; }
> }
>
> > * 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.
>
> > * 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
>
> :)
> :
> > * 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
> doesn't sound like an overly complex change.  Internally we use Qt's
> animation API for all this stuff, so it might even happen automatically if
> the animation API gains that sort of functionality.
>
> Cheers,
>
> Aaron
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel