QML and Qt Quick

Hi, At least here it is stated that the callback should not be denifed before calling "open" https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest#Properties

It is duplicated with https://bugreports.qt-project.org/browse/QTBUG-29686

I got some help from a couple of experts on IRC (#qt-qml) last night and my example is working now. I've answered the StackOverflow question that I linked to above if anyone is interested.

Not sure if you're still interested, but I had a conversation with a couple of former Trolltech employees on IRC last night. They helped me with this and I've posted the answer to my StackOverflow question.

This is exactly what http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-loader.html#using-a-loader-within-a-view-delegate tells about :) Moving the sub-delegate inside the parent delegate, or to a separate file, should make it work. With the Desktop Components example that was mentioned, it should be the same.

[quote author="amund_l" date="1364392619"]Included in QtCreator 2.7 is the "OpenGL under QML":http://qt-project.org/doc/qt-5.0/qtquick/quick-scenegraph-openglunderqml.html. This might be what you are looking for. It let you explore the new feature where QML is redered on top of your OpenGL ES context, so you can merge your OpenGL and QtQuick UI. Pretty cool.[/quote] Well...apart from perspective, rotating in more then one direction, an ambitious model loader that calculates matrices like Jackson Pollock before it hands over to QGLAbstract scene which is even more liberal... Yeah....Polys are for chumps :) https://www.shadertoy.com/

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.