kinetic-declarative plasma integration

[Alan Alpert]

Here's the answers to the rest of your questions :)

On Thursday 14 May 2009 10:30:09 Aaron J. Seigo wrote:

> * in the examples i see that the QmlComponent is creating a QGraphicsItem
> as its root component. was there any reason for not using a QGraphicsWidget
> there that we should be aware of, or was that just a "this is an example,
> it doesn't have to perfect" sort of thing? because we can't reasonably use
> QGraphicsItems in something like plasma without doing a bunch of manual
> geometry management. in the weather example with the finishLoad method, due
> to this manual geometry management, it will break the user's settings.
> really, the m_root item needs to conform to the container, not the other
> way around.

Mostly it was due to it being an example. We didn't want to limit root 
components to being QGraphicsWidgets as then the other (non-plasma) examples 
would need some changes to get running. If we restricted valid QML for the 
plasma script engine to need a QGraphicsWidget as the root then we could 
probably avoid the manual geometry management. Certainly the breaking of the 
user's settings is just due to it being an incomplete example.

> i get the impression, actually, that this has been designed with fixed
> screen sizes in mind. while this will work just swimingly on something like
> a phone or a tablet device, it seems to be of extremely limited utility on
> a more flexible device.

Declarative UI should still work well with flexible devices, as you can make 
sizes and positions relative to the size of the root element (or any other 
element).

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

Due to rapid change during earlier development a lot of things like this may 
have slipped into the examples, especially the plasma integration. Some of the 
cleanup and changes, like this one, may have been missed when fixing up the 
example code. It's unfortunate and I'll look into cleaning it up as soon as I 
can.

> * i see that there are QFxItem wrappers for things like Plasma::Svg. will
> we need to wrap every element for it to be available? that seems highly
> unwieldly, as we'll have to track API additions and changes; why isn't
> QMetaObject providing the magic for us here?

You're right again. You don't have to wrap every element for it to be 
available, and you can just use the QMetaObject magic. You can just expose the 
QObject directly and use all of its QPROPERTYs and QINVOKABLEs in QML. The 
final plasma integration would probably do this, but it might require some code 
changes to make it easy to use the objects from QML.

Using QFxItem wrappers is just the way we decided to implement the examples, 
as it meant we didn't have to alter the plasma source at all to get a 
declarative interface on the items. It would also have been possible to create 
the declarative interface in QML.

> * 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?
>
> * same for question for other resources like pictures
If you write your own items you can do whatever you want. This means you can 
have a file property which first searches in some special directories, and then 
uses the QML loader if it can't find it. The KSvgItem in the plasma integration 
almost does this, it has a file property that finds the file using Plasma::Svg 
does. It doesn't currently fall back to anything if that fails, but it could.

> * 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?
You can definitely do whatever you want in C++, including creating QML items 
dynamically. Aside from the repeater it is tricky to do from javascript, 
though it is possible.

> * 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?"

Both of those examples are possible and could easily be used instead of pixel 
values. Below is the QML for what I think you mean, and you could just use 
that instead of width or x being absolute pixel values.

Item {
	anchors.right: sun.left
}

Item {
	width: page.width-x 
	x: y
}

-- 
Alan Alpert