QML and Qt Quick

I got it, guys. When we set @width: rect.width * 0.5;@ is happening a binding. Not an assignment. What I should do to assign the value: @Component.onCompleted: { width = rect.width * 0.5; }@

In the future perhaps, hopefully, for 5.0 and 5.0.1 doc building failed for me (and not just me) and only HTML docs were generated, and worse than the online version - the missing snippets are still missing, plus there is entire articles that are missing too.

Hi All, everything works fine in 5.1! Thanks everybody. If somebody need help please let me know...

Ah, sorry for not being clear about my intentions. I'm trying to build an app using Ubuntu's new QML-based SDK, which has developers building app in pure QML. An example can be found "here":http://developer.ubuntu.com/resources/app-developer-cookbook/mobile/currency-converter-phone-app/. I'd like to build an app that interfaces with a third-party API, and I'd like to build that particular piece of functionality into a separate library.

Thank you for your input Chris, the point about this post, as hinted in the title, is to pass information from the place where the Loader Element is used to instantiate an arbitrary object, to the created object. The information passed, serves no deeper purpose then to be passed. It seems I've chosen a confusing example. Sorry about that. Maybe this will clarify: main.qml @import QtQuick 2.0 Rectangle { width: 360; height: 360 color: "aliceblue" Rectangle { anchors.centerIn: parent width: 300; height: 300 border {color: "black"; width: 1 } Container { anchors.margins: 1 aThing: Rectangle { width: 200; height: 200; border {color: "black"; width: 1 } Text { anchors.fill: parent; anchors.margins: 3; text: passedInformation wrapMode: Text.WordWrap } } } } } @ Container.qml: @import QtQuick 2.0 Rectangle { id: root property Component aThing: Item { } anchors.fill: parent color: "lightsteelblue" Loader { property string passedInformation: "some arbitrary information" anchors.centerIn: parent sourceComponent: aThing } } @

Okay i solved the problem, see this for an explanation i wrote regarding it (applies to qt quick 1 / qt 4.8 at the time). [quote]There appears to be a problem in Qt when trying to bind to model data that you are unsure the existence of. When binding normally, such as name: model.data , if model.data is undefined then the ‘name’ property will be overwritten with ‘undefined’, as opposed to not being bound to, where it would be free to supply its own default value / logic. A way around this is to use a Binding element, for example: @Binding { target: tempButton property: "displayString" value: model.displayString when: true }@ For some reason, even if you specify to always bind (like in the example above – when: true), an undefined value will not be bound. This is almost what you might expect as default binding behavior but is inconsistent with the previous method, where the property would get bound to undefined data. Even with the ‘when’ omitted, it is still more awkward (and potentially slower?) to bind in this way, as you have to specify an id for the object that will be the target of the binding. You cannot just specify the Binding element’s parent as a target, as this doesn’t appear to work for some reason – you have to specifically give the target an id.[/quote]

I find the solution of above problem. problem is related to continous intterupt received by CPU from SD card io driver which leads to poor perfromance of whole system.

I have re-checked the case with a clear project and came to the idea that my observations were dependent on what I do when properties of an object are being set. That last time I had a sistem which automatically sets up a GUI element onWindowChanged (for that object) event if it is possible (new window is fine). So what really depends on simple/well syntax is which properties of parent object are set first. I suppose with simple-syntax the default property is resolved and set first of all, when using well-syntax results in properties resolved in order they appear in QML description. @// 1: Image { window: system.graphic ButtonSilver { x: 20; y: 170; } } // 2: Image { window: system.graphic content: [ ButtonSilver { x: 20; y: 170; } ] }@ With option "1" I've got "content" property for Image resolved and set first, and then "window" was set, resulting in gui-Image backend instantiated later then it was done for a button backend. Hence option "2" provides more kind of expected order, which however shouldn't matter as QML is declarative language. It is up to me to make my plugin as declarative as QML expects.

Thank you, Chris, this seems more like it is in Qt sources: custom append function implemented for property. I think such an implementation really gives you more control over the situation, will give it a try. However, @{ connect(t, SIGNAL(somePropertyChangeSignal()), obj, SLOT(doWhatever())); ... emit obj->mylistpropertyChanged(); }@ I'd use metacall for that, if connect is to be made each call like here. May be you wanted to say connect is somewhere else around. But I got the point, thanks.

Out of interest, why do you use two QQuickViews to implement this use-case? Can't you use a single engine to manage the object hierarchy? Cheers, Chris.

Actually, the keyword "this" has specific meaning defined in binding expressions, however is undefined in signal handlers and other dynamic functions. See http://qt-project.org/doc/qt-5.0/qtqml/qtqml-javascript-hostenvironment.html for more information.

Yes.. Great.. Thanks for help. :)

This is good news, I just read your post in the mailing lists, after double-checking that it is not an April's fool I'd say I am glad there is work being done in this direction and will be waiting for some examples.

What I've found is that currently the easiest way to know whenever the GridView's currently selected index has changed is to create a helper class that has a Qt metasystem registered property: @ Q_PROPERTY( int selectedIndex READ selectedIndex WRITE setSelectedIndex NOTIFY selectedIndexChanged ) @ Then make your helper class accessible by QML: @ qmlRegisterType< ItemSelectionModelQmlHelper >( "Models.Tools", 1, 0, "ItemSelectionModelQmlHelper" ); @ Then create an instantiate of this class and expose it to QML: @ QDeclarativeView* const view = new QDeclarativeView; ItemSelectionModelQmlHelper* const helper = new ItemSelectionModelQmlHelper( this ); view->rootContex()->setContextProperty( "_itemSelectionModelQmlHelper", helper ); @ Then one can create the QItemSelectionModel and listen to the helper's signal, so that to set the current index of the QItemSelectionModel. Of course as mentioned above, if you use a sorting or filtration of the data being displayed in the GridView the currently selected GridView item's index may not correspond to a row in your QAbstractItemModel derived class. This won't be the case if you have done the filtration and/or sorting in C++ using the QSortFilterProxyModel. The problem with the non-coresponding index will arise only if you do the sorting/filtration in QML. It would be best if GridView has the option to specify a selection model.

Oops sure. ^^' Now, it's just : @C:\Dvl[...]\src\main.cpp:34: erreur : no matching function for call to 'QObject::connect(ImageManager*&, const char*, QQuickItem*&, const char*)'@ Was just a stupid problem of import...

Hm, thank you very much, I'll now go and derive from QDeclarativeParserStatus. I didn't want QDeclarativeItem because I don't need all of those built-in utils for visualization, but this status-class is exactly what I need. bq. QDeclarativeParserStatus provides a mechanism for classes instantiated by a QDeclarativeEngine to receive notification at key points in their creation. This class is often used for optimization purposes, as it allows you to defer an expensive operation until after all the properties have been set on an object.