Hi, On 06/11/2010, at 1:12 AM, ext Jerzy Chalupski wrote: > I've been reading about and playing with Qt Quick for the last few > days and I have some questions: > > 1. I've always thought QML was supposed to be used strictly for > presentation layer of application, but in "declarative" examples and > demos usually whole logic is implemented in qml and javascript. Is > that an approach that you want to encourage (despite of breaking the > separation between presentation/business layers)?
Any particular examples/demos you are thinking of? While in some cases the logic may be scattered throughout, I don't think putting the business logic in JS *necessarily* means we need to break that separation -- e.g. in the case of samegame all of the game logic is in a single JS file, which doesn't seem conceptually different than implementing the logic in C++ (likewise, minehunt could have implemented it's logic in a JS file rather than C++). > 2. Is there any official (i.e. the one that will be shipped with Qt > Quick in the future) set of standard primitives or widgets (absolutely > necessary for consistent look between apps)? What do you mean by primitives? (In the past, we've used that word to describe the Rectangle, Image, Text, etc elements) In terms of widgets, Qt Components (http://qt.gitorious.org/qt-components) is the official project for that. > 3. How one should deploy a QML application? In the examples I found > some apps that keep qml files in Qt Resource system and create > QDeclarativeView/Engine inside main.cpp and load QML from "qml:" URL. > Is that a way to go? The other approach would be providing QML files > in unchanged form in some subdirectory. > > 4. It seems that access to qrc and filesystem from QML is mutually > exclusive. What about QML which resides in qrc (to hide it from > users), but needs to read some graphics from filesystem (for example > theme resources)? Neither exposing qml files, nor keeping all data in > qrc doesn't sound good. The filesystem should still be accessible to a QML file within a qrc, using the explicit "file://" prefix (though it may be that only absolute paths are supported that way?). This is probably something we should look at more closely (if you run into any specific issues, please let us know). > 5. I'm wondering what's the best approach for integrating C++ engine > and QML UI. One way is to expose C++ QObject to QML by > QDeclarativeContext::setContextObjext() or > QDeclarativeContext::setContextProperty(). The other way is to get > root QML component from QDeclarativeView::rootObject() method (and > optionally find the QML object using QObject::findChild() if we need > some other object than root object). (In general we've discouraged reaching deep into the QML tree from C++ using QObject::findChild(), as that tends to blur the business/presentation logic.) > Here's the list of things I'd like to be able to do: > 1. Send signal from QML to C++ (for example to change the state of > state machine when QML button is pressed). > 2. Have properties of QML components and C++ class synchronized > 3. Be able to call QML-side slots. > > The third item on the list may seem redundant, i.e. the same can be > achieved by setting some property and have a QML state with "when" > condition linked to that property, but I think it's much clearer to > have qmlUi->startFluffyBunnyAnimation(); in C++ code than > engine->setFluffyBunnyAnimationStarted(true) (not to mention that the > startFluffyBunnyAnimation() is a slot and can be directly connected to > some signal). I haven't really worked on a big C++/QML hybrid app, so I don't have a lot of practical experience here, but in general I like the idea that C++ just exposes some information (e.g. I'm loading a resource now) and the QML decides how to react (okay, I'm playing a load animation in response), rather than C++ directly telling QML "do this now". (3) may be entirely appropriate in some (or many) circumstances, I'd love to hear more from those using this type of approach. > The first two items can be done using first approach (exposing C++ > QObject to QML), but it requires a lot of boilerplate code (14 lines > of code per property): We'd definitely like to minimize the hassle of boilerplate code; one related suggestion is http://bugreports.qt.nokia.com/browse/QTCREATORBUG-1532. > class Engine : public QObject > { > Q_OBJECT > Q_PROPERTY(int myStuff READ myStuff WRITE setMyStuff > NOTIFY myStuffChanged) > > public: > explicit Engine(QObject *parent = 0) : > QObject(parent), > mMyStuff(0) > { > } > > int myStuff() const > { > return mMyStuff; > } > > void setMyStuff(int newStuff) > { > if (newStuff != mMyStuff) { > mMyStuff = newStuff; > emit myStuffChanged(); > } > } > > signals: > void myStuffChanged(); > > private: > int mMyStuff; > > }; > > Besides, I still can't call QML functions. I found QtObject QML > component and it looks promising: > > // my main qml file > import Qt 4.7 > > Item { > id: ui > > QtObject { > // id and objectName are intentionally different: > // from QML point of view, this object represents the engine > // from C++ point of view, this object represents UI > id: engine > objectName: qmlUi > > // property > property string myStuff > > signal foo() > > // slot from C++ perspective > function bar() { console.log("Bar"); } > } > > Text { > id: someLabel > text: engine.myStuff > } > > } > > The engine can be moved to separate file, which can be shared between > engine and UI teams. Is that correct approach or am I missing > something? That looks interesting. I think the top-level item in a QML/C++ app often ends up functioning a lot like your engine class (just not separated out that way). Note that with the above you'd want the engine assigned to something like "property QtObject engine" on the ui item, to make it accessible throughout the QML scope chain. Thanks for the excellent questions. Regards, Michael _______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
