Re: kinetic-declarative plasma integration
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" 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 Data
Re: kinetic-declarative plasma integration
Hi Marco,
On 15/05/09 7:10 AM, "ext Marco Martin" wrote:
>>> * 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?
The documentation is still a work in progress. In the specific case of the
views available, however, I think its ok. From the main page, navigate to
"Declarative Module"/"Qml Elements" and then look under the "Views" heading.
Incase you haven't generated the documentation, but want to get going fast,
here are the specific answers to your questions :)
You can set a ListView into horizontal mode by setting the "orientation"
property, like this:
ListView {
orientation: "Horizontal"
}
You can plug a QAbstractItemModel Qt model into our views, with one small
extra step. Because we expose each model role as a JavaScript property, not
an integer enumeration value, we need a way to map between the role ints in
your C++ model and textual representations. We've added a "void
QAbstractItemModel:: setRoleNames(const QHash &roleNames)"
method to let you specify this mapping.
So, to hook this all up:
// Setup role mapping
QHash roleNames;
roleNames.insert(1023, "myRoleName");
myModel->setRoleNames(roleNames);
// Bind the C++ model instance into a QML context
QmlContext *context = new QmlContext(engine->rootContext());
context->setContextProperty("myModel", static_cast(myModel));
// This is the example QML text that we'll instantiate
#define QML_TEXT "Rect { color: "white"; ListView { anchors.fill: parent;
delegate: Text { text: myRoleName } model: myModel } }"
// Create a QML component that uses the model
QmlComponent component(engine, QML_TEXT);
component->create(context);
This will give you a fairly boring list containing the text of the
"myRoleName" role for each entry in your model.
Cheers,
Aaron
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kinetic-declarative plasma integration
Hi Marco, On 15/05/09 11:34 PM, "ext Marco Martin" wrote: > tanks a lot for the input on qmodels, i assumed the qt docs were missing on > that part, now i've generated them and i see.. > > what i'm looking about specifically is seeing how feasible is to use those > list views in the gsoc i'm mentoring about a plasma based mediacenter (well, > depends also when we want to release something, before or after 4.6) > > so i'm looking on what we would need in that case: > > doesn't seems to be any way to set the currentIndex of any of the views simply > by clicking on an item (can implement a mouseRegion on the delegate, but > doesn't seem to be a way for the item to know what is its index into the > view?) Now you *have* found some limitations in our documentation :) You're correct in that the way to select an item on click is to have the delegate contain a MouseRegion that does it. By design we've tried to limit codifying "behavior" (like click to select) into our elements; preferring the flexibility of allowing the designer to define it as they see fit. Of course there is a balance to strike here - convenience vs flexibility - and whether or not we've got it right is another question. The index of an item is available magically to the delegate as the "index" context property. A delegate can check whether it is the current item by comparing its index to the list's currentIndex, or by using an "attached property". Attached properties are a concept we borrowed from Windows Presentation Foundation which allow one object to augment another with addition properties - in this case the ListView class adds a "ListView.isCurrentItem" property to the *root* element of the delegate. I've attached a simple example that implements click to select, and also changes the selected item's color. > PathView doesn't seem to be controllable with the keyboard (even by > implementing KeyActions into the delegate and changing the active index > doesn't seem to work, but nothing automatic anyways) Having default keyboard behavior for a PathView is tricky - depending on the shape of the path you might want any one of the up/down/left/right keys to move forwards and backwards in the items. So we took the easy way out and left it up to the user :) I've attached an example showing how to use KeyActions to key left and right through the PathView items. This is one of the balancing acts I mentioned above where we feel that its a little too far to the flexible/inconvenient side - I expect that we'll probably eventually add a way of setting a default key behavior for PathView so that you don't have to do this every time. > is there a way for an item to notice when it becomes active and changing its > state as a consequence? i.e, having the active item maybe slightly bigger and > with more info, like the recipes example (but here the item zooming is > triggered by a mouse click) This is also demonstrated in the listview example I mention above. Cheers, Aaron pathview.qml Description: pathview.qml listview.qml Description: listview.qml ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kinetic-declarative plasma integration
Hi Marco, On 16/05/09 5:53 AM, "ext Marco Martin" wrote: > neat, quite straightforward. > but i see that ListView has ListView.isCurrentItem GridView > GridView.isCurrentItem and so on.. > i think would be better to have that property consistently named, like > ItemView.isCurrentItem so that would be easier moving delegates between > different list types? (maybe keeping the ListView.* if there are properties > specific of a particular view?) This is a good idea. When we next do an API review, we'll investigate more sensible grouping of these properties. > > what i've come up is attached, it's a first rough example of a view more or > less of the same shape i think we could be interested for the mediacenter > gsoc.. > it shows some problems tough, they could be things that i did wrong or bugs.. > > the highlight covers first item while it's behind the other ones (this happens > in the shipped examples too) i guess wrong z value? Whoops, our bad. If you sync to 0add74a9339a9d7dda302aa4f31cbb50bdb69908 it should be fixed. > anchors, should be updated automatically? i have the icon with the property > anchors.horizontalCenter: parent.horizontalCenter, but when i make it bigger > the image is no longer centered: does the horizontal position have to be > explicitly updated in the state definition or should be done automatically? Anchors certainly should be automatically updated. You're specific problem was caused by a silly rounding error. This, too, should be fixed by commit 0add74a9339a9d7dda302aa4f31cbb50bdb69908. > and finally the last :) i enlarge the grid cells with key bindings, this works > except for a thing: the active item is in the state "Details", and when it > gets back to the normal state the size of the icon is not updated, and i think > it should, since the base width is defined from the cell size? (for inactive > items works fine) I'm not sure I understand this problem. Could you give a bit more detail/an example of it not working? > i'm a bit in a nagging mode but i hope this kind of feedback will be useful ;) Definitely useful! Cheers, Aaron ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
